New Year to All.
I noticed that the Vulnerability of OpenSSl111.1.1.1w still not fixed the latest release. See the following snippet.
Do we have some schedule or plan to get this patched?
Appreciate it!
"
Currently running OPNsense 23.7.11 at Tue Jan 9 12:40:00 EST 2024
vulnxml file up-to-date
openssl111-1.1.1w is vulnerable:
OpenSSL -- DoS in DH generation
CVE: CVE-2023-5678
WWW: https://vuxml.FreeBSD.org/freebsd/a5956603-7e4f-11ee-9df6-84a93843eb75.html
1 problem(s) in 1 installed package(s) found.
***DONE***
"
Have you
actually even looked at that "vulnerability"? See this (https://www.openssl.org/news/secadv/20231106.txt).
The CVSS score is 3.3 (low) and I doubt that this could be exploited from outside OpnSense, since there are no users that could do this via CLI. That seems to be the reason why upstream says:
QuoteDue to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available.
Thank you for your quick reply.
But that is not my question. My question was not about the severity of this vul., nor the plan of OPenSSL.org, but about the OPNsense's plan to patch it.
Anyhow, your reply is highly appreciated.
Any answers about the OPnsense patching plan would be appreciated.
Quote from: buddystad on January 09, 2024, 08:02:40 PM
Any answers about the OPnsense patching plan would be appreciated.
You appear to have received your answer already. Any particular reason you believe that Opnsense's strategy should diverge from that of OpenSSL in this instance?
Quote from: buddystad on January 09, 2024, 08:02:40 PM
Thank you for your quick reply.
But that is not my question. My question was not about the severity of this vul., nor the plan of OPenSSL.org, but about the OPNsense's plan to patch it.
Anyhow, your reply is highly appreciated.
Any answers about the OPnsense patching plan would be appreciated.
O.K., sorry to break this to you in more clarity:
Though I cannot speak for the OpnSense developers, my educated guess is that there are no plans to patch this at all in OpnSense before new upstream releases become available. OpnSense is a FreeBSD derivative, which in turn uses OpenSSL - the originator of the ("vulnerable") software, thus it is two levels downstream from the origin of the problem.
As I already showed you,
OpenSSL themselves have no plans to patch this now. This means that is highly unlikely that the FreeBSD folks will patch it before the next regular OpenSSL release. Which in turn means I cannot imagine that OpnSense will patch it in face of no neccessity to do so.
That is just the way how stacked dependencies work in Open Source (tm). If you do not believe me, you can try to do a "vulnerability" scan of a fully up-to-date Ubuntu 22.04 LTS server with the likes of Wazuh or similar. You will find more than 100 current unpatched vulnerabilities, many of which are from Debian (upstream of Ubuntu) with a status of "wontfix" - just because the upstream package developers have no fix either.
Some people seem to not understand this and have the childish wish to fix any "vulnerability" that shows up in whatever context. Won't happen. I even know of regulations which demand companies to actively look and fix such vulnerabilities. Then people ask Open Source developers to fix problems at once, which often is only possible by using the next big thing (i.e. next release) of some upstream package. Alas, their developers often do not provide a backport fix because they have done a whole new release already, which in turn cannot be used because of new "features", aka incompatibilities which would have wide-ranging consequences along with the security fix.
OpenSSL is one good example for this. Matter-of-fact it is not long ago that FreeBSD switched from OpenSSL 1.0 to 1.1 because of incompatible features.
For these reasons, there are few exceptions to the rule "if upstream does not fix it, we won't, either". Probably with CVSS scores > 8, but only if the scenario allows exploitation, none of which is the case here.
Exactly. There seems to be a new source of "security consultants" who keep telling my hosting customers that they must fix this curl "vulnerability" *now* or pick a different hoster. The amount of work I have to put into explaining how systems work is getting exhausting.
Yes, Patrick: I often work for banks now undergoing this nonsense when their regulators and dumb auditors tell them to use such tools and services. More often than not, they were better off not knowing what vulnerabilities they have in stock.
One customer of mine rejected my advice to not scan his systems with Wazuh - which he was not obliged to do. Now they have more than 400 "vulnerabilities" from around 100 outdated packages, libraries and frameworks which they cannot fix.
The problem is: Now they know and must fix it. If something goes wrong now, they are in deep trouble. Their only viable alternative is to refrain using open source completely. I do not have to tell you that is impossible.
In the case of banks, they regularly have people of any sorts telling them they have found a "security vulnerability" and cheekily demanding a bug hunting reward.
Quote from: passeri on January 09, 2024, 10:00:39 PM
Quote from: buddystad on January 09, 2024, 08:02:40 PM
Any answers about the OPnsense patching plan would be appreciated.
You appear to have received your answer already. Any particular reason you believe that Opnsense's strategy should diverge from that of OpenSSL in this instance?
Hi,
Sorry I have no reason at all to believe they would switch or not. OPNsense team has the discretion about the choice off xxxxxSSL. This is why I was asking even though I know mostly and ususally they would not. As per my limited experience on the OPNsense, they used a FreeBSD that had the libreSSL in their base system, not sure though, and they switched to OpenSSL somewhere in the history.
thanks
FreeBSD never had LibreSSL in base but it can of course be installed from ports/packages.
There are settings in the ports build system that in theory let you replace OpenSSL with LibreSSL for your own package builds. In practice that lead to so many failed builds due to incompatibilities that OPNsense decided to drop LibreSSL altogether. I doubt they will ever reintroduce it.
This so called vulnerability is irrelevant. Just ignore it and care about more important things.
Quote from: meyergru on January 09, 2024, 10:15:59 PM
Quote from: buddystad on January 09, 2024, 08:02:40 PM
Thank you for your quick reply.
But that is not my question. My question was not about the severity of this vul., nor the plan of OPenSSL.org, but about the OPNsense's plan to patch it.
Anyhow, your reply is highly appreciated.
Any answers about the OPnsense patching plan would be appreciated.
O.K., sorry to break this to you in more clarity:
Though I cannot speak for the OpnSense developers, my educated guess is that there are no plans to patch this at all in OpnSense before new upstream releases become available. OpnSense is a FreeBSD derivative, which in turn uses OpenSSL - the originator of the ("vulnerable") software, thus it is two levels downstream from the origin of the problem.
As I already showed you, OpenSSL themselves have no plans to patch this now. This means that is highly unlikely that the FreeBSD folks will patch it before the next regular OpenSSL release. Which in turn means I cannot imagine that OpnSense will patch it in face of no neccessity to do so.
That is just the way how stacked dependencies work in Open Source (tm). If you do not believe me, you can try to do a "vulnerability" scan of a fully up-to-date Ubuntu 22.04 LTS server with the likes of Wazuh or similar. You will find more than 100 current unpatched vulnerabilities, many of which are from Debian (upstream of Ubuntu) with a status of "wontfix" - just because the upstream package developers have no fix either.
Some people seem to not understand this and have the childish wish to fix any "vulnerability" that shows up in whatever context. Won't happen. I even know of regulations which demand companies to actively look and fix such vulnerabilities. Then people ask Open Source developers to fix problems at once, which often is only possible by using the next big thing (i.e. next release) of some upstream package. Alas, their developers often do not provide a backport fix because they have done a whole new release already, which in turn cannot be used because of new "features", aka incompatibilities which would have wide-ranging consequences along with the security fix.
OpenSSL is one good example for this. Matter-of-fact it is not long ago that FreeBSD switched from OpenSSL 1.0 to 1.1 because of incompatible features.
For these reasons, there are few exceptions to the rule "if upstream does not fix it, we won't, either". Probably with CVSS scores > 8, but only if the scenario allows exploitation, none of which is the case here.
Thank you for your elaboration on this. You have nothing to be sorry about, my friend. Your reply is appreciated. I fully agree with you that open source providers/developers would usually not take action on the vulnerabilities lying in the upstream stuff, which is the default strategy. I was just curious if they have any plan. If not, some customers may think about switching to other options since some of them may have a very strict security policy in place, reasonable or not.
Again, Thank you guys. You replies are all informative and helpful.