CWEs vs CVEs – Identifying vs Responding to the Right Security Issues

Image

For the third time in under a year, I've had to analyze a CVE against a third-party library I use that is related to CWE-502 De-serializing of Untrusted Data. In each case, the library maintainers have pushed back, correctly in my opinion, that the problem is not in the library itself but in the hosting application. Fortunately for me, my application isn't exposed to this class of issue, but researching each of these issues creates work for me and makes me think about the broader issue that there is conflict between different uses and interpretations of the NVD CVE database. Consumers of the NVD like me want to quickly identify concrete issues in products or libraries. I hope that when looking at a CVE, I can determine quickly if I am exposed based on whether or not I use that library or application in that specific configuration. And in some ways, these CVEs fit the bill. If I use the library and I deserialize data from untrusted sources, I am at risk. The reporters of these CVEs are trying to communicate to the world that using a specific library may expose them to a vulnerability if they have a specific CWE like CWE 502. Their goal is to make the universe of library users (applications) aware of this risk. So far, everyone in these two camps are happy. Communication is happening and hopefully, security is increased a little bit. But developers of libraries are now having to respond to questions about the security of their library simply because it does something nominally benign until deployed into a dangerous environment. In fact, in the latest CVE I looked at, the serialization / de-serialization is a design feature. In all three cases I have looked at this year, the development teams have pushed back that the security issue is not in their code at all. The problem is that their users, application developers, de-serialize data without some form of trust established like authentication or controlling which objects can be de-serialized. And they are correct. If I use a library but don't build security into my product, the problem is mine and the CVE should be associated with my product – not the library I use. In an ideal world, this would work this way. But this is definitely not an ideal world. A problem is that the researchers are identifying vectors with which to exploit applications that have a specific CWE. There is no way for them to identify and file CVEs against all of the applications that have this CWE, so how do they help the world get safer? By filing a CVE against the library, they can inform application developers of potential risk. But that leaves the library developers with a CVE against their product that they dispute and might never resolve, especially if it is part of what they do by design. Another potential problem is that application developers are in the position where they can resolve specific third-party CVEs by upgrading the library to a version that has compensating controls or removes the offending class behavior. The disputed nature of the CVE may even lead them to ask for a waiver since the library vendor is never going to fix it. The underlying CWE instance may never get fixed as long as they can manipulate the CVE data. This also presents a problem for detection. Customers may identify a library on your path and assert you are vulnerable to CVE-X, forcing you to respond to an issue you may not be exposed to. This costs you time and money. The CVE database is a tool that I think is very valuable but this is one aspect of it that I find frustrating. On the one hand, filing a CVE is an effective, maybe even the most effective, way to inform library consumers of potential risk. On the other hand, it's kind of like blaming a transmission manufacturer for implementing neutral because the car maker allows the driver to leave the car in neutral without engaging the parking brake. Maybe the best thing about this whole situation is that it makes people think and talk about these security issues.