CVSSv3 was released this past summer and a number of vendors, including Tripwire, are beginning to adopt it both internally and within their tools. I wanted to talk about some of my favourite (and not-so-favourite) aspects of CVSSv3. Up first, we have the addition of Scope. I have a bit of a love-hate relationship with the notion of Scope. I think it’s important to be able to note a context shift (for example, a virtual machine or sandbox escape). I don’t, however, feel that a scope change should be the defining point in the ability for a vulnerability to score a 10.0. I also realize that this is the problem with any scoring algorithm; it’s something that I’ve spent many years discussing with the IP360 Scoring System. When you add a new category or distinction, you have to adhere to it or you risk devaluing the system. That means that while Scope is beneficial from an informational standpoint, the prevalence of 10.0 CVSS scores will go away. In fact, we should see very few scores that hit 10.0, with 9.8 being the new king of high end scoring in most cases. That said, it’s difficult to think of vulnerabilities like Shellshock (which scores a 9.8) or issues that give complete database access as not scoring a 10.0. One of the more interesting things to pay attention to will be various analysts' application of CVSSv2 scoring. I was never happy with many of the applied uses of CVSSv2, particularly the misuse of Access Vector to elevate scores. I’m afraid that we’ll see the same thing happen with Scope as people reach for the now elusive 10.0. Since I just mentioned it, let’s also discuss Access Vector, which has been renamed Attack Vector in CVSSv3. The CVSS SIG has also provided a very clear definition here:
A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed "remotely exploitable" and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers).
This should remove the incorrect “network” classification that you see in CVSSv2 from a number of products, such as Adobe Flash, PDF readers and web browsers. This is a great change and an excellent clarification. Again, the most interesting aspect will be to see how analysts apply this when calculating CVSSv3 scores. In keeping with that definition clarification, the CVSS SIG has done an excellent job of providing guidance and clarification via the User Guide and Scoring Examples. There’s a lot of really good documentation available to ensure that everyone understands the application of CVSSv3. That said, there’s still a point that I really disagree with and that’s the classification of man-in-the-middle (MitM) attacks. The guidance from the CVSS SIG is that MitM attacks should be classified as Attack Vector: Network and Attack Complexity: High. I agree with Attack Complexity: High but I’m not a fan of Attack Vector: Network. As a reminder, the options for Attack Vector are: Network, Adjacent, Local and Physical. The requirement to use Adjacent is that the attacker must need to be on the same physical or logical network, which is why it doesn’t apply to MitM attacks. This leaves me wondering if there’s an additional category that should exist between Network and Adjacent. Consider the following two vulnerabilities:
- A vulnerability in a telnet server. Anyone that connects to the server can exploit the vulnerability.
- A vulnerability in a telnet client. Any telnet server that you connect to can exploit the vulnerability.
Should these vulnerabilities have the same Attack Vector? I think that there’s a big difference between a listening service that anyone can attack and a vulnerable client that must first initiate a connection. In many ways, just as we went from Local in CVSSv2 to Physical and Local in CVSSv3, I think that we need to make another move when we visit the next version of the standard from Network to Network Ingress and Network Egress, where Network Ingress ultimately scores higher than Network Egress. Given the current values assigned to the attack vectors: Network 0.85 Adjacent 0.62 Local 0.55 Physical 0.2 It would be very easy to modify and add an additional level: Network Ingress 0.85 Adjacent Network 0.62 Network Egress 0.59 Local 0.55 Physical 0.2 It is, of course, entirely possibly to try and argue that this is a moot point, since another newly added vector is User Interaction. I feel that these are different enough that it’s ok. While it’s true that most Network Egress items would also require User Interaction, there are definitely outbound connections that don’t require it. I feel that there’s enough wiggle room that you could make use of User Interaction (an awesome additional vector) and still find value in the Network Ingress vs Network Egress split. At this point, you could move attacks like MitM and issues affecting clients making outbound connections to the lower scoring category. In order to better highlight this, let’s take a look at a vulnerability from the CVSS Examples document and how the addition of Ingress/Egress would affect the score of a vulnerability: CVE-2012-5376 currently scores a 10.0 in CVSSv2 and a 9.6 in CVSSv3.0. Remember, ShellShock is a 9.8 under 3.0, so we’re not seeing much distinction between a Google Chrome vulnerability that requires somebody purposely browse to a website and a vulnerability that is exploitable simply because it’s online. If we use the 0.59 value listed above for Network Egress, suddenly that Google Chrome vulnerability becomes an 8.7. Still high enough to be considered a serious risk to an environment but now there’s enough differentiation between it and ShellShock to recognize the more serious vulnerability. This is a change that I’d like to see in a point revision of CVSSv3 or in CVSSv4. Other than that, I’m happy with a lot of the changes from CVSSv2 and I think that CVSSv3 is a much better standard overall with some much-needed clarification. Learn more about Tripwire vulnerability management tools. Title image courtesy of ShutterStock
