OpenSSL and CVE-2021-3711 / CVE-2021-3712 / any others

[PerpetualNewbie]

General question:

When there are updates to address security issues in non-pkg products like openssl, (system installed, not part of pkg install) do you usually back-port patches to the present version you have installed to keep the version-name the same, or do you upgrade openssl to the latest version for that Major/Minor release?

Specific question:
What are your plans (if any) with respect to https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3711 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3712 with openssl?

example# ls -l `which openssl`
-r-xr-xr-x  1 root  wheel  856888 Aug  2 04:20 /usr/bin/openssl

example# pkg which `which openssl`
/usr/bin/openssl was not found in the database
(because it is a system-provided collection of binaries/libraries (make buildworld), not from pkg)

# openssl version
OpenSSL 1.1.1d-freebsd  10 Sep 2019

On other FreeBSD / HardenedBSD systems, they appear to patch the branch for export to /usr/src/ as a repo, so that future "buildworld" can get the fix. With HardenedBSD, they appear to have back-ported the fixes for these CVE into the source code for openssl, then alter "./include/openssl/opensslv.h" #define for "OPENSSL_VERSION_TEXT" to append the date of the new/revised-code build of openssl.

If you plan to provide updates to address these CVE, would they take the form of a bump to the release (example, 21.7.1 -> 21.7.2) or a (signed) tarball or binary replacement, or some other process?

When such things are patched/addressed, is there a system-installed file to indicate which issues have been addressed for each installed product not from a package, or some DB to see when they were addressed and how to confirm the version installed has those patches? (I know about update notes, and they are useful, but am looking to see if these are also stored on the system.) I've tried checking /usr/share/openssl

Thanks!

[franco]

Base system patches are provided via FreeBSD security advisories and include OpenSSL patches to /usr/bin/openssl and libraries. In this case version numbers are not altered. This is what the operating system patch level is for (-pX).

However, we use OpenSSL/LibreSSL from the FreeBSD ports tree with proper version number assignment and released source code by the vendor with all the ups and downs of it. Although OpenSSL is in the base, it is not used in any third party software and vulnerable code therefore almost never used in practice.

All the current reports should be fixed in 21.7.2 when that comes along, which is suffering from a holiday season break at this point.


Cheers,
Franco

[PerpetualNewbie]

Thanks!

[meyergru]

Although OpenSSL is in the base, it is not used in any third party software and vulnerable code therefore almost never used in practice.

I beg your pardon, but is that really so?

Surely, somehow, the web frontend and other services must implement TLS.

Code: [Select]

# pkg required-depends openssl
freeradius3-3.0.23_1
libfido2-1.8.0
squid-4.15
mysql57-client-5.7.35_1
opnsense-update-21.7.1
php74-openssl-7.4.22_1
unbound-1.13.1
openldap-client-2.4.59_1
cyrus-sasl-gssapi-2.1.27_1
cyrus-sasl-2.1.27_2
krb5-1.19.2
nmap-7.91_1
git-2.32.0_1
hostapd-2.9_4
iperf3-3.10.1_1
isc-dhcp44-server-4.4.2P1_1
lighttpd-1.4.59
monit-5.28.0
mpd5-5.9
ntp-4.2.8p15
openssh-portable-8.6.p1,1
openvpn-2.5.3
ruby-2.7.4,1
strongswan-5.9.2_2
syslog-ng-3.33.2
wpa_supplicant-2.9_11
cpdup-1.22
ldns-1.7.1_2
curl-7.78.0
libevent-2.1.12
py38-cryptography-3.3.2
python38-3.8.11

So, at least php, python, squid, curl and even openssh can make use of the openssl library, among many others. And so does lighthttp - which is what listens to port 443:

Code: [Select]

# sockstat -l | fgrep :443
root     lighttpd   85837 5  tcp4   *:443                 *:*
root     lighttpd   85837 6  tcp6   *:443                 *:*

And lighthttp indirectly uses /usr/local/lib/libssl.so.11 (contained in openssl 1.1.1k) via mod_openssl.so:

Code: [Select]

# ldd /usr/local/lib/lighttpd/mod_openssl.so
/usr/local/lib/lighttpd/mod_openssl.so:
        libssl.so.11 => /usr/local/lib/libssl.so.11 (0x5e143c01000)
        libcrypto.so.11 => /usr/local/lib/libcrypto.so.11 (0x5e143ca2000)
        libc.so.7 => /lib/libc.so.7 (0x5e103126000)
        libthr.so.3 => /lib/libthr.so.3 (0x5e1030ba000)

It rather looks to me as if at least the web frontend is affected by the openssl 1.1.1k vulnerabilities which would already be a strong enough reason for a hotfix.

[franco]

I beg your pardon, but is that really so?

Please don't gloss over the first half of the same paragraph you are quoting.

/usr/bin/openssl et al. as OpenSSL from the BASE (operating) system

/usr/local/bin/openssl et al. as OpenSSL/LibreSSL from the PORTS tree


Cheers,
Franco

[meyergru]

O.K., so what you really mean is that the (vulnerable) FreeBSD system library is not being used by most of the packages and thus are of no concern, however, the one that Opnsense packages use is also vulnerable until it will be fixed with 21.7.2.

Or shorter: Yes, Opensense is currently vulnerable - technical details aside.

But the good news is that the underlying FreeBSD version does not have to be upgraded to fix this, just the Opnsense packages on top of it.

[Greelan]

Franco literally said in his earlier post that “all the current reports should be fixed in 21.7.2”. So precisely what point are you trying to make now? Seems to me that you entirely misread his earlier post, and your “gotcha” attempts have misfired on all fronts

[franco]

I'm working on the FreeBSD security advisories today. Looks tike there is some code drift in 12.1 / 12.2 used versions source code that interferes with the fix but I think we can ship with all the fixes included as stated before.


Cheers,
Franco

[meyergru]

Franco literally said in his earlier post that “all the current reports should be fixed in 21.7.2”. So precisely what point are you trying to make now? Seems to me that you entirely misread his earlier post, and your “gotcha” attempts have misfired on all fronts

I came in here searching the forum for "CVE-2021-3711" and this was the only thread to come up.

Yes, I got Franco wrong and that is about the first gotcha: I - and possibly others - misunderstood this as "OpenSSL is contained in Opnsense, but never being used anyway, and even that will be fixed in 21.7.2". Which is not what Franco said, but could be implied. The difference between the two versions of the OpenSSL library in Opnsense is irrelevant from a security perspective (that was why I discussed how Opnsense is vulnerable at this time, I know now that Franco never denied this anyway).

My second point is that because of this, Opnsense is completely vulnerable as of now and will only be fixed when 21.7.2 comes out. With ransomware on the rise, Shodan and toolkits for vulnerability exploitation, this has big potential for a large-scale attack should anybody expose any OpenSSL-based Opnsense service to the internet (do you?). One of my friends just had a Junglesec ransomware attack based on a similar unfixed vulnerability in IPMI.

So, IMHO, there should be neither soothing nor misleading messages about the problem, but a quick fix (tm), which Franco is doing right now.

Alas, with chains of dependencies like OpenSSL -> FreeBSD -> Opnsense (or OpenSSL -> Linux -> NAS Software), a fix in the base tool takes a while to descend down into the leaf products (QNAP and Synology just announced to fix the same vulnerability). Opnsense has made the right choice to avoid the FreeBSD dependency on OpenSSL (3rd point, no gotcha here).

[mimugmail]

The biggest point many ppl misunderstood is, that OPNsense is an appliance, like Sophos, Fortigate, Cisco etc. All use this open source software but it's not a plain Debian or Redhat, where you get an update when it's released. Vendors bundle such things in a release, like Microsoft and Oracle and all others.

P.S.: Your friend really shouldn't make an IPMI public

[Greelan]

So, IMHO, there should be neither soothing nor misleading messages about the problem, but a quick fix (tm), which Franco is doing right now.

Franco’s post was not in my view meant to be “soothing” (if that is meant to imply a deflection of the issue) and it certainly was not misleading. He answered the specific question about how OpenSSL was incorporated in OPNsense, and then said that the latest advisories would be addressed in the next release. You are throwing undeserved shade

[meyergru]

P.S.: Your friend really shouldn't make an IPMI public

Slightly off topic: We sure know that now  . However, with a hosted machine, IPMI access is often a last resort to be able to remotely fix things in case an update goes wrong... about as vital as Opnsense remote access when you manage friends' and families' networks.

Limiting to specific IPs or networks maybe feasible somewhere, but not in Germany, as most ISPs hand out dynamic IPs. 2FA does not help against vulnerabilities... basically, I don't have a good answer to that problem...

Franco’s post was not in my view meant to be “soothing” (if that is meant to imply a deflection of the issue) and it certainly was not misleading. He answered the specific question about how OpenSSL was incorporated in OPNsense, and then said that the latest advisories would be addressed in the next release. You are throwing undeserved shade

The statement mislead me, as I explained. I never meant to say Franco's statement was "intentionally" misleading. Notwithstanding, with security questions, I prefer unmistakable language, even if somebody like me just "glosses over it" - more like the proverbial "lark's vomit" ;-)

[pankaj]

Guys,

A quick question, I set up OpenVPN few days back just to learn and have the ability to access home network from outside. Seems like a fix for this vulnerability would be released in the coming weeks.

But I'd like to temporary disable the OpenVPN (not remove it) till it is fixed, just to be on the safe side.

Would disabling the OpenVPN rules do the job or is there a better way?

Thanks,

PS: I also disabled the WAN rules that were opening port 1194.

[mimugmail]

Tick the arrow VPN : Openvpn : Server

[franco]

Yeah I would also disable OpenVPN server. It's the easiest thing to find later during troubleshoot if it's forgotten.

21.7.2 is due tomorrow.


Cheers,
Franco