We’ll start with the important stuff: the widely awaited OpenSSL bugfixes announced last week are out.

OpenSSL 1.1.1 goes to version 1.1.1s, and patches one listed security-related bug, but this bug doesn’t have a security rating or an official CVE number.

We strongly recommend that you update, but the CRITICAL update that you will have seen in the cybersecurity media does not apply to this version.

OpenSSL 3.0 goes to version 3.0.7, and patches not one but two CVE-numbered security bugs that are official designated at HIGH severity.

We strongly recommend that you update, with as much urgency as you can muster, but the CRITICAL fix that everyone has been talking about has now been downgraded to HIGH severity.

This reflects the opinion of the OpenSSL team:

Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described [in the release notes] have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

Ironically, a second and similar bug, dubbed CVE-2022-3786, was discovered while the fix for CVE-2022-3602 was being prepared.

The original bug only allows an attacker to corrupt four bytes on the stack, which limits the exploitability of the hole, while the second bug allows an unlimited amout of stack overflow, but apparently only of the “dot” character (ASCII 46, or 0x2E) repeated over and over again.

Both vulnerabilities are exposed during TLS certificate verification, where a booby-trapped client or server “identifies” itself to the server or client at the other end with a deliberately malformed TLS certificate.

Although these sorts of stack overflow (one of limited size and the other of limited data values) sound as though they will be hard to exploit for code execution (especially in 64-bit software, where four bytes is only half of a memory address)…

…they are almost certain to be easily exploitable for DoS (denial of service) attacks, where the sender of a rogue certificate could crash the recipient of that certificate at will.

Fortunately, most TLS exchanges involve clients verifying server certificates, and not the other way around.

Most web servers, for instance, don’t require visitors to identify themselves with a certificate before allowing them to read the site, so the “crash direction” of any working exploits is likely to be rogue servers crashing hapless visitors, which is generally considered much less severe than servers crashing every time they’re browsed to by a single rogue visitor.

Nevertheless, any technique by which a hacked web or email server can gratuitously crash a visiting browser or email app must be considered dangerous, not least because any attempt by the client software to retry the connection will result in the app crashing over and over and over again.

You therefore definitely want to patch against this as soon as you can.

What to do?

As mentioned above, you need OpenSSL 1.1.1s or OpenSSL 3.0.7 to replace whatever version you have at the moment.

OpenSSL 1.1.1s gets a security patch described as fixing “a regression [an old bug that reappeared] introduced in OpenSSL 1.1.1r not refreshing the certificate data to be signed before signing the certificate”, that bug doesn’t have a severity or a CVE assigned to it…

…but don’t let that put you off updating as soon as you can.

OpenSSL 3.0.7 gets the two CVE-numbered HIGH-severity fixes listed above, and even though they don’t sound quite as scary now as they did in the news-fest leading up to this release, you should assume that:

• Many attackers will quickly figure out how to exploit these hole for DoS purposes. That could cause workflow disruption at best, and cybersecurity trouble at worst, especially if the bug can be abused to slow down or break important automated processes (such as updates) in your IT ecosystem.
• Some attackers may be able to wrangle these bugs for remote code execution. This would give criminals a good chance of using booby-trapped web servers to subvert client software used for secure downloads in your own business.
• If a proof-of-concept (PoC) does get found, it will attract huge interest. As you will remember from Log4Shell, as soon as PoCs were published, thousands of self-proclaimed “researchers” jumped on the scan-the-internet-and-attack-as-you-go bandwagon under the guise of “helping” people find problems on their networks.

Note that OpenSSL 1.0.2 is still supported and updated, but privately only, for customers who have paid contracts with the OpenSSL team, which is why we don’t have any information to disclose about it here, other than to confirm that the CVE-numbered bugs in OpenSSL 3.0 don’t apply to the OpenSSL 1.0.2 series.

You can read more, and get your OpenSSL updates, from the OpenSSL website.

Note also that Google’s BoringSSL library, Firefox’s Network Security Services (NSS), and OpenBSD’s LibreSSL, all of which provide similar functionality to OpenSSL (and in the case of LibreSSL, is closely compatibile with it) are all unaffected by these bugs.

Oh, and if PoCs do start to show up online, please don’t be a clever-clogs and start “trying out” those PoCs against other people’s computers under the impression that you are “helping” with any sort of “research”.