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 officially described as 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 flaw, while the second bug allows an arbitrary amout of stack overflow, but apparently only with the “dot” character (ASCII 46, or 0x2E) in every overflowed byte.
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 denial-of-service (DoS) 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 vector” 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”.
This bug in 1.1.1 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, however, gets fixes for 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 update, 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 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 transactions 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.
OpenSSL 1.0.2, as it happens, is still supported and updated, but privately only, for customers who have paid contracts with the OpenSSL team.
That’s why we don’t have any information to disclose about 1.0.2 here, other than to confirm that the CVE-numbered bugs in OpenSSL 3.0 aren’t present in the OpenSSL 1.0.2 code.
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”.
8 comments on “OpenSSL patches are out – CRITICAL bug downgraded to HIGH, but patch anyway!”
I have no idea what I’m supposed to update. Chrome? Firefox? Windows?
Ahhh, the $64,000 question. In fact, perhaps the $64,000,000,000 question, given how complicated it gets and how quickly.
Windows has its own cryptographic library called CNG (Crypto Next Generation) and its own secure browsing component called SChannel. (You don’t need to know those names, but you might see them around in future.) So Windows doesn’t come with OpenSSL out of the box.
Firefox uses its own cryptographic library called NSS (Network Security Services), which is completely separate from OpenSSL.Therefore there is no update needed for Firefox.
As far as I know, Chrome either uses the built-in Windows cryptographic code, SChannel, or its own library called BoringSSL, which is also separate from OpenSSL. Therefore Chrome doesn’t need updating either!
And Edge oin Windows doesn’t use OpenSSL, either.
If this sounds confusing, and if you are wondering if that is s why I didn’t try to “explain everything” in the article, you are right! It’s *is* very confusing…
…and it gets even worse, because most programs on Windows don’t use OpenSSL, which isn’t even installed as part of the operating system, but there is nothing to stop some software from bringing along its own copy of OpenSSL, so although you probably don’t have it, it might be there without you even realising. And even worser, if you have two products that use it, they might each bring their own independent *and different* version, and stash them in two totally different places.
If you have any Macs, well, they do come with OpenSSL (but not version 3.0 as far as I know), *and* with their own cryptographic library, which (of course, this can on;y get harder) has its own unique name, Secure Transport, which is what Safari uses.
Linux, widely used on servers, generally does come with OpenSSL, and each distro chooses its own flavour. Some have OpenSSL 1.1.1, some have OpenSSL 3.0, and some may have both. For Linux computers, consult your IT team or your distro provider for advice. You can expect most Linux distros to update their core install of OpenSSL in the next day or two, so you should get that update in the usual way.
In short: if you have Windows laptop + Chrome + Firefox then your browsing is *not* affected and you don’t have to worry about that.
I hope that helps to be going on with.
I may try to add some “hunting for OpenSSL” advice to the article, and it will of necessity be at least mildly technical, but in the meantime, I think you can relax. The browsers you use should operate in blissful ignotance of this.
It was shared with me that this is built into some VPN/tunnel products, and should be looked into by companies.
But I don’t know this firsthand myself.
Probably in lots of routers, too, though most I have seen recently aren’t yet on OpenSSL 3.
If it’s a Linux VPN that’s effectively an app on your box, it may well use the OpenSSL that comes with the distro, in which case updating your distro is a good start. For appliances, routers, etc., you should consult the vendor…
what about Sophos products such as Sophos UTM and Sophos Firewall? Are they affected, are there updates for them?
They are not affected (not least because they don’t use OpenSSL 3.0), so they don’t need updates for this.
For a full list, please see:
How a bug that is enormously complex for exploitation and can only be used for DOS (availability attacks) continue being classified as HIGH? We all understood that openssl team never heard of CVSS but this doesn’t mean nobody else did!
Firstly, it’s not a certainty that it will only ever lead to DoS, notably given that the potential exploitability depends on many external factors such as compiler settings used when building and code bitness. Secondly, exploitable DoS failures in security validation code should always be considered serious, given that they could lead to security bypasses. (See our recent article on the SHA-3 bug in the XKCP codebase, inherited by PHP 8 and some Pythons.)
Be wary of letting CVSS become a sort of religious talisman… a “tail that wags the dog”, if you like, a “litres per 100km” number on a car’s showroom windscreen sticker.
I don’t doubt for a moment that if the OpenSSL team had downgraded this to MEDIUM there would have been plenty of observers to accuse them of trying to downplay poor coding or to understate the possible risk.
They’ve provided the source code, a description of the bug, and some guidelines for assessing it… if you insist on a CVSS score then all the facts are there to decide where you think it would fit in a numerical bug rating system. I suspect that a single score for these bugs based on code that could appear in binary form with many different degrees of risk and exploitability based on how it was built is a bit like trying to come up with a single fuel consumption figure for “all vehicles using a specific engine from manufacturer X”.