Unless you have not been checking important software security news recently, OpenSSL has experienced a “critical” vulnerability scare, which has now been patched with a new release. Now, after some of the dust has settled, let’s discuss what has actually happened and what the remediation involves.

How did the weaknesses come to be?

Studying the code base, historical records reveal that, in essence, both CVEs that were fixed were due to buggy implementation of the punycode decoding function, introduced in a single Pull Request (PR), originally committed on 2019 and approved on 2020.

A thorough read through the PR’s correspondence gives us a first glimpse into patterns that might have affected the result. 

Note – Of course, hind-sight is 20/20, and we are not here to accuse but to learn from the past and offer improvements and lessons learned as those situations might arise in any environment, organization and group that follows secure coding practices.

As pointed out by the developers, no test suite is available for punycode, as the RFC detailing punycode decode does not provide such tests. This makes the difficulty level of reviewing and analyzing the code more problematic.

Also to note that context is key here – while decoding functions, especially that their input variables are user controlled, we can benefit from realizing this is a big material change and probably includes security implications. This emphasizes further the importance of someone competent in decoding related attacks to be reviewing the code commits.

Then, some small changes, mainly cosmetic, were put into the punycode.c file (more on that later), a year after its conception.

Patch analysis – punycode decoder

Domain names were standardized in a funny fashion, as time progressed and more domain names wanted to have a familiar name under Unicode without breaking the internet infrastructure as a whole – a mid-ground solution was proposed.

Even when dealing with important security issues, we genuinely appreciate the subtle humor that goes into the patch – as commented on the patch’s conversation –

CVE-2022-3602 

Although a classic error, those are sneaky vulnerabilities. Being off-by-one check for length, a single bite overflow could have crashed the system. The fix is as simple as it looks – include the case in which the length is also equal to the max length to be ignored.

Chronologically speaking – this CVE was the first of the two to be found, while the researcher that discovered the fault researched it, he came across the second CVE that will be explained further below.

CVE-2022-3786

The second CVE of which demanded a bit more code changes to be able to circumvent the weakness presented by haphazardly puny decoding the presented hostname. 

The major piece of the material change is shown here:

Essentially, prior to the patch the limits of the decoded input were not properly defined, hence resulting in a potential out-of-bound overflow on memcpy(), which is widely known as a function that needs to be handled with care from that exact reason, which it doesn’t employ bounds-check.

How to discover vulnerable assets?

When controlling your inventory, you can use SCA tools, such as Apiiro’s SCA engine, to discover packages, libraries and dependencies that rely on vulnerable versions of OpenSSL – 3.0.0 up to 3.0.6 were found to be vulnerable.

One should pay close attention to sub-dependencies in code. For example, Python’s cryptography module is dependent on OpenSSL at the back-end, tightly coupled with the module version that is an appropriate OpenSSL version. Keeping an eye on those cases is not always a trivial task. They can be discovered by SCA tools or keeping an eye on publications revolving around the aforementioned CVE designators.

Remediation

Patched version 3.0.7 fixes both CVEs mentioned, updating your environments to that version or above. Versions outside of 3.0.0-3.0.6 are not considered to be vulnerable and no action is required.

—

Have you explored how Apiiro helps detect & fix critical risks such as OSS & API vulnerabilities, design flaws, secrets and Infra-as-Code across the software supply chain? The first step to remediation is visibility and our platform can help you gain the visibility to risk as well as build automation to make sure vulnerabilities are prioritized with context and remediated before they become critical security breaches. Book a demo to learn more.