Context security: When is a CVE not a CVE?

There are some general principles for dealing with vulnerabilities that can be used to help guide security thinking and decision-making. 

First, it is always important to understand what we are protecting as this has implications for the actions we need to take. For example, if our artifact is a web server, then we need to protect it from untrusted users. If our artifact is cryptographic software, then we obviously need to protect it, even from users with physical access to the system. In each case, we clearly distinguish what the risk boundaries are and where we need to focus.

Second, configuration is part of the code base. If a malicious actor has access to your configuration, it's basically the same as if that malicious actor has access to your code base.

Given the tsunami of vulnerable systems caused by the recent Log4j 2.x vulnerability (Log4Shell), we as a security organization may be searching more closely for other potential vulnerabilities. However, perhaps we should also take this opportunity to pause and reflect before rushing to judge every potential security issue we find in our code. Cooler heads might also suggest that not everything that causes a safety issue is necessarily classified as equal.

As an example, we can look at the recent CVE-2021-4104 allocation against Log4j 1.x through this lens. Exploiting this requires direct access to the configuration file to manipulate settings. A similar topic is now emerging around the Logback project, along with examples from the Node community.

Let's be clear, exposing potential vulnerabilities is still a good thing. But in the midst of a media scare, it’s also appropriate to explore our own critical thinking and reestablish the community baseline on which we should be paying attention. Creating another tsunami of potential vulnerabilities could do more harm than good, further overwhelming already overstressed security teams and disrupting the industry's ongoing efforts to protect open source software.

Thinking critically about CVE
The discussion identified in the above thread raises some very interesting questions.

For example, if a vulnerability requires privileged access to files inside the system to be exploited, is it really a vulnerability? Almost any significant modern software can be configured to allow unsafe operations. On a similar note, it's entirely possible that sshd has been configured to allow logins with a blank password. Should we consider this a new vulnerability in sshd?

One of the mechanisms our security team uses is the idea of considering expected versus unexpected behavior. If a piece of software can be configured to execute remote code and this functionality is well documented, is it an act that provides a vulnerability that can be exploited? This can be considered expected behavior rather than actually being a security vulnerability in itself.

Should we design software to have no unsafe configurable patterns? This can be seen as a laudable goal, but it conflicts somewhat with the way we have designed open source software for the past 30 or more years. A typical design goal for open source software is to achieve the highest level of configurability to allow all use cases. In recent years, sensible security defaults have become a secondary goal, but the principle has always been to give users the choice to configure software in any way they see fit, safe, or unsafe.

We also currently live in a world where CVEs are both easy to raise by individuals and companies and are valuable because of their credibility and cacheability. This unique combination can lead to problematic assignments. On the other hand, having the ability to report potential security issues frictionlessly can only be a positive thing, so we are faced with something of a paradox.

As an industry, we're getting better and better at identifying vulnerabilities while creating a lot more software, so it's easy to see the potential for overload.

Properly identifying vulnerabilities in software, assessing them and providing mitigation measures is a very resource-intensive and largely manual process, especially for complex cases. While machine learning methods are becoming increasingly useful, and artificial intelligence may prove more valuable, in many cases (ironically) computers are not that useful to us in diagnosis.

Looking to the future
The discussion points outlined here are not intended to change any specific CVE, but rather to start a conversation about the future of vulnerability assessment and what we consider insecure now and in the future. Building robust and general open source software suitable for common use cases inevitably results in configurable modes that provide more or less security. If we want to continue doing this, it's also the user's responsibility to understand the pitfalls of use. Perhaps the answer is better documentation and education, as well as triage of potential vulnerabilities in normal use cases.

Reference: https://snyk.io/blog/when-is-a-cve-not-a-cve/