Heads Up: Critical OpenSSL 3.x Vulnerability Disclosing 11/1/2022

It was only a matter of time until we had to deal with this fun again… OpenSSL 3.0.7 is a security-fix release. The highest severity issue fixed in this release is CRITICAL.

Considering how tight-lipped they are being regarding this patch, it has to be truly serious. Suggest folks take a peek for potential impacts (i.e. applications leveraging OpenSSL 3.x libraries) to get ahead of the game since we really have no idea the scope or vectors yet.

3 Likes

Which begs the question: how can we best use BigFix to identify OpenSSL 3.x.x in our environments?

1 Like

Agreed

I was tasked with doing that here, so I am digging in today to see what I can come up with.

@JasonWalker will the scan process used in log4j and or the Apache Commons vulnerabilities work in a situation such as this?

OpenSSL is…a lot harder.
There will be some products on the Linux side that would use the system-wide OpenSSL libraries…that should be a pretty easy RPM/YUM/apt package upgrade.

There will be others that embed an OpenSSL and keep the library separate; the library could have a bunch of different names. If there’s a naming convention we can key on, like OpenSSL.dll or OpenSSL.so then…maybe.

And then the really difficult part. A lot of programs (including BigFix itself) will have static-built their OpenSSL dependency so it’s…just part of the executable. You’d need a static executable analysis tool to detect those (something like BlackDuck), and there are likely hundreds of software titles built this way. I do have some things in mind to use YARA binary-file scanning, but it would be much more “beta” than the other filesystem scans I’ve built lately, harder to setup (one has to compile YARA from source on Linux/UNIX, there’s not a binary distribution), and will take a lot longer to run (since it has to examine every byte of every executable, and not just run a directory listing).

Where the OS software vendors put out their own updates, we’ll of course build update fixlets for those products we cover, but finding the in-house or older/unsupported software is more difficult.

I think the network scanner tools (Tenable, Qualys, etc.) will have a greater role in detecting this through port-scanning and network traffic analysis…more like HeartBleed.

3 Likes

I have been tasked that here as well. They are wanting me to try to find a way to discover any and all OpenSSL versions, regardless to the 3.x vulnerability. I do not think the higher ups understand much these days

Scanning options:

Great resources, thanks @fermt

Will you be developing content based on this ?

*** Nothing finalized, everything subject to change, and this is not an official position from BigFix ***

I’m meeting with the team in a couple of hours. A lot of what we end up doing will be based on exactly what the vulnerability turns out to be, and how it can be detected.

We’ll of course be publishing the normal vendor updates for system-wide OpenSSL installations (expected on RHEL 8 and higher, and Ubuntu 22 I believe) when the OS vendors release their packages.

I’m looking at things with YARA but it’s resource-intensive, and delivering YARA to the endpoint can be complex (on Linux/Mac it has to be built from source code, there’s no binary distribution; on Windows it has some undocumented dependencies on Visual C++ runtime)

We’re also waiting for the vulnerability details to see whether we can detect it with a network probe, like we did for HeartBleed (check the BigFix Labs site for some interesting content based on perform loopback network scans on the endpoint to detect HeartBleed)

1 Like

The vulnerabilities have been disclosed, https://www.openssl.org/news/vulnerabilities.html

Good news is that the Critical has been downgraded to High based on the complexity and mitigating factors.

Bad news is that it affects both OpenSSL 3.x Client and Server, and there don’t appear to be effective port-scanning methods to detect it.

We’ll be posting a new Forum thread with detection content in a bit. Expect Patch content for the OS vendors that provide OpenSSL 3 (Ubuntu, Red Hat, etc.), Inventory signatures to detect openssl libraries in the filesystem, and a new class of scanning task that uses YARA scanning to detect openssl in compiled binaries.

2 Likes

Started a new thread specific to the BigFix response on this at OpenSSL 3 vulnerabilities 2022-11-01

Includes pre-release content (with large disclaimers) if you would like to test our new YARA scanning content (on Windows-only for the moment). I’ll be updating that post as Inventory signatures and vendor update fixlets become available.