This week I woke up to find several emails from Nexus Lifecycle indicating that the products in my portfolio were potentially vulnerable due to their inclusion of Apache commons-collection. If you have no idea what I’m talking about, stop now and go read this factual and un-sensationalized account of the situation. I’ll wait.

Ok, now that you’re back, let’s dive into this a bit more. Of course even though I received the mails this morning, this wasn’t the first I knew about this vulnerability. The product that alerted me happens to be one that I oversee at Sonatype, and knowing about these things is what we do.

First Visibility

If we roll the clock back a bit, we first heard about this over the weekend when the original FoxGlove blog post was published. Our data team immediately went to work digging into the details and assessing the situation. As you’ve read above, this one is unique in that there isn’t a specific place to point a finger.

Commons-collection is not vulnerable in isolation and deserialization is also not a dangerous operation when performed correctly. Because the Commons-collections:InvokerTransformer is serializable and allows command execution and because your application allows untrusted deserialization you have an exploitable combination. As of the time of this writing, there is no actual CVE filed to alert most vendors and consumers.

Automation of Policy Violations

For a long time now, we’ve supported the automation of detecting policy violations based on attributes such as quality, license and security information. Along the way, we’ve discovered a lot of vulnerability disclosures to be lacking. Many people assume that NVD (the National Vulnerability Database) is a curated repository of information but it’s not. The actual content of the disclosure is written by the project team that requested the id in the first place, many of which are not experienced application security practitioners.

As with anything in life and software, there are outstanding examples of well written disclosures, and there are worst-case scenarios where the actual disclosure was never followed up and you find merely a placeholder years after the release. In between you find descriptions written for ops teams or security specialists but not for the rest of us who write or manage software. (Do you know what a Bleichenbacher attack is and why it’s really scary?) Sometimes the disclosures focus on a whole application but neglect to name the actual root cause that exists in a 3rd party library. You might be using that very same library completely unaware that you are actually vulnerable.

On top of the content issues, the data itself is not automatable without lots of potential false positives. You need precise matching of your libraries against the affected versions in the disclosure in order to rapidly send alert emails or take automatic action to stop further damage without causing wasted effort caused by false alarms.

Behind the Scenes: What Did We Find?

All of this is a long way of saying that there’s a lot of work behind the scenes of those alert emails I received yesterday. Our data team reviews each issue and provides expanded data aimed at answering the following types of questions:

• What does this CVE mean?
• How do I know I’m vulnerable?
• How do I fix it?
• Why is this showing up in my scan? I don’t use commons-collections!
  (hint, it’s there transitively or something you do use has embedded it)
• Is there a known attack?

All of this is then immediately pushed out to our customers where their policy uses the data to determine how to respond. The default configuration would cause alerts to go out for anything we’ve previously analyzed that is affected. It will also show up in developer’s IDEs, CI builds, deployment dashboards etc and, if desired, block attempts to promote builds, releases or deployments until it’s fixed.

Additionally, the Nexus IQ Server dashboard will indicate every application in their portfolio that has this problem so immediate remediation efforts can be targeted at the highest risk applications. While other people are somewhere between completely unaware or scrambling to determine if and where they are affected, our users are already triaging and remediating.

Immediate Notification but No Official Disclosure: Why?

We felt the potential risk of this vulnerability warranted immediate notification to our customers despite the fact that there isn’t an official disclosure via NVD. We created our own and pushed that data to our system which you can see here.

The Follow Up

I predict that this is just the first of what will become a class of disclosures in the immediate future, as more researchers (good and bad) will inevitably be looking for the next class that can be used during deserialization to do bad things. We will repeat the above process and update the disclosure with affected versions, classes and fixes as this continues to unfold.

So, if you didn’t get this alert today and don’t know if you’re affected, what are you waiting for? Get one of our Nexus solutions so you are among the first to know next time.

P.S.

Nexus Repository Manager and Nexus IQ Server are not affected by this particular vulnerability. Although both include commons-collections, we implemented deserialization whitelisting last year in response to the xstream disclosure, which was substantially the same problem. If you haven’t done the same, you might want to get moving because the bad guys aren’t sitting around.