As a new Nexus User, I read your blog post about the new openssl vulnerability and I know that sometimes the purpose of blog posts is simply to create awareness and attract new people to a website and not just to intensely promote your products. So I think the blog post is interesting but triggers this question to me: how Nexus can help to detect this new openssl vulnerability and fix the apprioriate components?
In particular, this part of the blog post retained my attention :
I looked at some of these java librairies you quoted, and most of them seems to link openssl dynamically, it means that scanning these java librairies will not help us to detect openssl vulnerabilities, and even knowning that we use these java librairies in our organization seems useless.
Even if we suppose that a vulnerable openssl version is statically linked into a component xyz, then the maintainer of xyz should recompile it with openssl version 3.0.7 in order to publish a fixed version of xyz, and in this case it’s likely another CVE, different from the openssl one, that will be used to track vulnerable versions of xyz.
So what we need in this context is, I believe, to scan for openssl native libraries in the production and development environments of an organization? if I am correct on this assumption, then why did you take the time to redirect us to these Java librairies on Maven Central? It’s even more surprising because:
Nexus supports apk, apt, yum formats.
I am not sure, but it also means that Nexus firewall is available for apk, apt, yum repos?
Nexus IQ is able to scan yum packages.
So we almost have (Nexus IQ doesn’t support apt, apk yet) all the features in the Nexus solution to detect, scan and block openssl vulnerabilities? In particular the inventory that you mention in your blog post:
can be achievable by doing a scan in Nexus IQ or through the continuous monitoring feature?
Heya! You have reached the author of the blog. Thanks for the feedback first and foremost, you are bringing up some very insightful questions that I wasn’t able to address at the time. The TLDR of below is agreed, we’ll aim to add product specific help in future incident blogs to make thing easier
The main goal of the blog, much like during the ones we published with log4shell and spring4shell, was to create public clarity around very many conflicting messages in the industry around a vulnerability that had potentially a wide impact, but was yet unreleased. It was written as a point in time and intended at a wider audience, and we followed it up later with another post that talks about the vulnerabilities in depth.
I looked at some of these java librairies you quoted, and most of them seems to link openssl dynamically, it means that scanning these java librairies will not help us to detect openssl vulnerabilities, and even knowning that we use these java librairies in our organization seems useless.
In the cases of larger security vulnerabilities, we try and find ways of sharing information that is publicly useful, such as the impact assessment. In this case, the only affected packages really are the openssl 3.x versions, but historically a silent killer in many vulnerabilities is the potential inclusion of the package transitively. e.g. the JndiManager.class causing log4shell is also present in 19562 other packages. Having awareness of not just direct references can help assess true impact. 98% of all vulnerabilities downloaded have fixes, but for whatever reason are not chosen by the consumers. In the heat of the moment wanted to make sure there was a reference in there to stir up awareness that it might also come in via these inclusions.
Even if we suppose that a vulnerable openssl version is statically linked into a component xyz, then the maintainer of xyz should recompile it with openssl version 3.0.7 in order to publish a fixed version of xyz, and in this case it’s likely another CVE, different from the openssl one, that will be used to track vulnerable versions of xyz.
Although you can’t necessarily fix it yourself, awareness of these issues is key in an incident management response. Knowing something might be pulling in a vulnerability is important for containment and being open source our advice is to advocate for projects to issue fixes. We for example see a ton of transitive inclusions of vulnerable classes in static linking cases, not just in the above l4shell example, but also with things like jquery.js being bundled in dozens of times resulting in all sort of shenanigans.
In most cases with static linking like this, there wont be a separate CVE that the project opens, and instead the info is lost in bug trackers and issues in github. This is why the Data service exists in IQ and why we do secondary expansion to identify hidden issues like this.
Nexus supports apk, apt, yum formats.
APK is a community format, Debian and RPM registries are supported in nexus: Formats
You can use NXRMs api to search for impacted packages. APIDOCS located in NEXUSBASEURL/admin/system/api or Admin view - system - API - search
I am not sure, but it also means that Nexus firewall is available for apk, apt, yum repos?
can be achievable by doing a scan in Nexus IQ or through the continuous monitoring feature?
Yes, the recommendation is to be alerted by this via continuous monitoring. There is a great best practices guide on how to deal with 0-days hidden in the Lifecycle / Firewall documentation I recommend reading. 0-Day Vulnerability Best Practices
