Is a vulnerability exploitable when it’s not exploitable?

In my last post, I described an important issue regarding VEX that hasn’t yet been discussed in any published document (but should be): the question of how to handle the fact that how a user interprets a statement that a vulnerability is exploitable in a product or not (which of course is the purpose of VEX) is going to depend heavily on what kind of attacker they think they face. This is important, since if the user’s assumption on hacker skill level diverges substantially from the supplier’s assumption, they may draw exactly the wrong conclusion from what the supplier intended, when they designated a vulnerability as exploitable or not in their product.

There is another issue, which like the first hasn’t been discussed in print at all but is also important (although it was discussed a good deal within the NTIA-now-CISA VEX working group, as was the hacker skill level issue): the question of how the supplier, in preparing a VEX statement, should account for the environment in which it’s installed, especially any security controls. Here are some forms in which this question comes up:

1.      Say a vulnerability is normally not exploitable unless a default configuration setting is changed. If a user makes that change (either deliberately or inadvertently), does that make the vulnerability is exploitable in the product, meaning its status in a VEX statement should be “affected”?

2.      Now let’s say a vulnerability, which would otherwise be exploitable, will be rendered not exploitable by a product configuration setting recommended in writing by the supplier (but not made part of the default configuration). Should the supplier list the VEX status of that vulnerability in the product as “affected”? After all, the user might not follow their recommendation.

3.      If the supplier recommends their product not be connected to the internet and says a particular vulnerability isn’t exploitable, yet a user connects the product to the internet anyway and gets compromised through an exploit of that vulnerability, does this mean the vulnerability was in fact exploitable?

4.      What if the supplier says a vulnerability isn’t exploitable if their product isn’t connected to the internet, yet because of how the product operates, it would be difficult to use the product efficiently if it weren’t connected? If the vulnerability is exploited and the user suffers some loss because of that, is this the supplier’s fault or the user’s? After all, the supplier said the vulnerability isn’t exploitable if the product isn’t connected to the internet.

5.      What if a supplier recommends deploying their product securely but doesn’t describe what that means, and a user mistakenly doesn’t put the product behind a firewall? If the product gets compromised because of the lack of a firewall, is this the supplier’s fault for not explicitly stating the need for one?

6.      What if a supplier assumes that users will normally install a web application firewall, yet doesn’t state that explicitly in their installation instructions? A user has a normal stateful inspection firewall but not a WAF, and they get compromised through a vulnerability that the WAF would have protected against. Is this their fault or the supplier’s? Or is it neither’s fault?

7.      What if the supplier has issued a patch for a vulnerability? Is the vulnerability exploitable or not?

Here’s what I think the rule should be for cases like this (and they come up all the time): The supplier should assume that a) The user has followed any configuration or environment settings the supplier has recommended in writing, and b) the user hasn’t changed any default settings, and c) The user has followed basic security best practices (although the supplier doesn’t have to state exactly what they think those best practices are).

However, the supplier should, whenever they think there might be any question in the user’s mind about how the product should be configured, or what would constitute a security best practice in a particular case, always take an extra step and state explicitly what they have in mind. Here is how I would answer each question:

1.      A default configuration setting constitutes a very strong recommendation from the supplier that they want the user to leave it in place, meaning the supplier is justified in believing that the user won’t change the setting. Thus, the vulnerability would have a “not affected” (i.e., not exploitable) VEX status. However, it certainly might save both the supplier and their customers a lot of headaches if the supplier points out explicitly in their documentation that the configuration setting is required to prevent exploitation of that vulnerability, and if the user changes it, they risk being compromised because of their action.

2.      This is a lot like the first question, but the difference is that in this case, the configuration setting is just recommended, not made part of the default configuration. Nevertheless, in my opinion, the supplier is justified in assuming the user has followed the recommendation. Therefore, the VEX status should be “not affected”. Again, it would help if the supplier explicitly pointed out in their documentation that changing this default setting might make them vulnerable to an attack.

3.      This is in effect the same as the second question. The supplier has made an installation recommendation and is justified in assuming it will be followed. Again, the status for the vulnerability should be “not affected”.

4.      This is superficially the same as the third question, but is in effect very different. I would hope that no supplier would take such a cynical approach as to require the user do something that makes their product unusable, but I’m sure there are a few that can and will do this. In this case, the supplier is assigning a “not affected” status, but they’re basing that on the assumption that the user won't use the product as it's intended to be used - which is obviously horse manure. A customer who sees something like this happen more than once might want to re-evaluate whether they wish to stay with this supplier. Who knows what other shady steps they’re taking?

5.      In my opinion, a firewall is basic security best practice. No supplier should have to tell their users to put in a firewall. Therefore, the supplier should say the vulnerability isn’t exploitable (“not affected”).

6.      I don’t consider a WAF to be a basic security best practice. If the supplier thinks one is needed to protect their product, they should state it explicitly, not just assume it. Therefore, the supplier should list the status of the vulnerability as “affected” and list the WAF as a mitigation for the vulnerability.

7.      It’s important to keep in mind that the question is never whether the product itself is vulnerable, but whether a particular version of the product is vulnerable. If Product A version 2.0.0 is vulnerable to CVE-2023-12345 but a patch has been issued for that vulnerability, the patched version must have a new version string, say v2.0.1. Moreover, if the user applies the patch to v2.0.0, the version of their instance should change to 2.0.1. This is required both for VEX to work and for support reasons, since if multiple codebases have the same version number, the product becomes unsupportable. So, the status of v2.0.0 should be “affected”, but the status of v2.0.1 should be “fixed” or “not affected”. The mitigation that goes with the “affected” status for v2.0.0 might be “upgrade to v2.0.1” or “Apply patch XYZ, available at (URL)”, or perhaps both.

This issue, as well as the hacker skill level issue that I discussed in my previous post, is one that needs to be discussed and documented. With both issues, there isn’t one “right” answer, but there does need to be some articulated position, so that both suppliers and users will interpret the status settings correctly. It’s to address issues like this that a VEX playbook is needed. It might be developed by the CISA VEX working group; it might be developed by the SBOM Forum; or it might be developed by some other group where people discuss issues with SBOM and VEX. But it needs to be developed. 

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.