Editor's note: Sonatype tooling has not been impacted by the vulnerabilities mentioned in this article.
It’s been a week since we were warned about the OpenSSL vulnerability. The internet has been on fire with speculation and preemptive advertisements for all sorts of products and services.
Today we have more information about the vulnerability, including a blog article that went live with the disclosure. Sonatype has concluded a deep dive into the vulnerability and intelligence that we will be providing our Sonatype Platform users ASAP.
Sonatype products are not affected by the OpenSSL vulnerabilities.
The disclosure shows us that the vulnerability may open us up to a denial of service (DOS) attack, but it does not appear to facilitate data exfiltration or remote code execution (RCE). The original critical vulnerability is now split into two vulnerabilities ranked as "High" Severity.
In this article, we won’t be going into detail about how the vulnerability came to be or even how to patch it (in short: upgrade to the latest). Instead, we'll be taking a quick look at what an exploit against these two new issues could be able to do- and compare it to two other common dependency exploits.
What it is not: Data exfiltration
When you look at OpenSSL as a tool and then take a look at a variety of "exfil" attacks… You may have spent all last week speculating that a new exfil technique has been identified. That's understandable because Out-of-Band (OoB) attacks are common targets of public web applications and REST APIs that use OpenSSL.
Several examples of OoB attacks may be used to exfiltrate data, including delayed cross-site scripting (XSS), server side request forgery (SSRF), and even email header injection.
The thing OoB attacks have in common is that they target an unexpected source that is externally accessible. The typical solution to preventing data exfiltration, especially from OoB attacks, is a firewall with strict egress rules.
What it probably isn’t: Remote code execution
This category of attack has some overlap with data exfiltration in that a common vector of attack is OoB, as we described above. Out-of-band remote code execution (OoB RCE) is even its own category of attack. Anyone reading this is likely to fondly remember Log4Shell, a widespread Java vulnerability related to remote code execution.
RCE vulnerabilities open us up to a wide range of attacks because the attacker can do anything your network allows it to do. If your firewall doesn't have strict ingress rules, RCE may be a vector to introduce malware, cryptominers, or simply allow any variety of other malicious activities.
The two vulnerabilities each allow for buffer overflows to occur, which can be used to generate an RCE, but the project discovered that real-life mitigations in most operating systems most likely prevent this.
According to the disclosure:
"Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler."
This is the reason why the two vulnerabilities were classed as "High" severities instead of "Critical." Be sure this applies to your situation, or else you may be vulnerable to RCE attacks.
What it definitely is: Denial of service
Denial of Service is obviously a big deal, but it's also far more manageable and less terrifying than remote code execution. DOS attacks are not always easily identified and mitigated, but they are limited in scope.
If the OpenSSL vulnerability is not patched everywhere in your ecosystem, then vulnerable machines may be rendered useless – increasing your infrastructure costs and decreasing your application availability.
Resolving the matter: Dependency management
We've had a week's notice to try and identify everywhere that OpenSSL is installed. If this was a painful process for you (or if you haven't finished yet), you may want to learn about some tools that streamline dependency management at scale.
The importance of automated dependency management is immense: To this day, approximately one-third of all Log4j installations are still using the version that contains the Log4Shell vulnerability.
Security vulnerabilities of varying severities occur in open source all the time - and we as organizations use a ton of it. Having a well-thought-out process is important to help you automatically chart what is used where. Moreover, reacting appropriately to new security issues is vital to keeping on top of the daily deluge of issues being pushed out.
Once you've identified the places where you've installed OpenSSL 3, it's time to patch! Simply update every instance of OpenSSL 3 to the version that was released today, and you're done with that step. If this is an extremely painful process, you're doing something wrong.
The understandably painful part is in your transitive dependencies (the dependencies of your dependencies) and in any hidden culprits.
Today, some vendors and open source projects have already begun to issue precautionary OpenSSL 3 patches to avoid any issues. NodeJs and VMware are examples of quick responders working to prevent you from introducing transitive dependency vulnerabilities.
One last thing: Hidden culprits
Any automated dependency manager worth its salt will help you resolve your transitive dependencies (good luck if you’re working manually!), but the hidden culprits are another beast entirely.
When Log4Shell took the world by storm, the Security Research team at Sonatype, with the help of their trusty machine learning algorithms, were able to identify 783 packages in the Java ecosystem that had copy-pasted the offending code into their own open source tools. These are the hidden culprits.
If you're using any of those packages today, I'm sorry to tell you that you're still vulnerable to Log4Shell. (Fortunately for our customers, we automatically add those hidden culprits to the OSS Index that powers our software).
So that's it. Fix your dependencies, fix your transitive dependencies, and make sure you don’t have any hidden culprits. Have a happy OpenSSL day!
