What Makes a Vulnerability "Theoretical"
Accuracy matters.
The Code Curmudgeon posted about "theoretical" vulnerabilities recently. Having spent almost 20 years doing manual code review, penetration testing, and deciphering the output of security tools... it's a topic I'm interested in. I tried twice to post this as a comment, but it never made it to the site.
I think the Curmudgeon completely misunderstood what people mean when they call a vulnerability theoretical. He provides an extended example using the Lenovo Superfish situation, which to me is not a theoretical vulnerability at all. It's a real vulnerability that was probably not exploited. That's a theoretical exploit, not a theoretical vulnerability.
"Since the private key can easily be recovered from the Superfish software, an attacker can generate a certificate for any website that will be trusted by a system with the Superfish software installed." That's real and exploitable. I don't think Lenovo was arguing that the vulnerability was theoretical, but that it was caught in time so no big deal. Terrible response, but not trying to deny the realness of the vulnerability.
But there are *plenty* of vulnerabilities reported that *are* theoretical. For example, both static and dynamic analysis tools have extremely high false alarm rates. That means that all the vulnerabilities from these tools *are* theoretical because we do not yet know for sure that they are real. The work to triage these findings is hard manual work, but it's the only to make sure they are *real* vulnerabilities.
One might argue that it is simply cheaper to "fix" all vulnerabilities, whether they are theoretical or known to be real. But this results in developers or other skilled team members spending precious time working on code that isn't broken and doesn't need changing. I've seen static tools generate tens of thousands of these vulnerabilities for a single app. (Actually it's way higher than that, but nobody would believe me if I gave the real numbers). So "fix everything" destroys the trust between security and development teams, and undermines the good work done by security teams.
So the problem isn't that people aren't fixing theoretical vulnerabilities. It's that security is producing them at an astounding rate. We can do better.
Experienced Application Security developer, OWASP ESAPI project co-lead / committer, secure code reviews
9 年So did Code Curmudgeon substantially rewrite his blog post after he finally received your comments? Because based on what I've read, I don't think he was arguing that Superfish was a theoretical vulnerability at all. Quite the opposite, in fact. For instance, Code Curmudgeon wrote this comment "The idea that a vulnerability is merely theoretical is not only ignorant but dangerous. Software exploits occur because bad actors operate by finding unexpected loopholes in a software system. ... Software vulnerabilities are exactly like unlocked doors. They are not theoretical, they are actual whole or openings in your software than can and probably will be exploited." Lenovo was the one who, caught with their pants down, called out the vulnerability as being "theoretical", not Code Curmudgeon...at least based on what he _currently_ has posted on his blog. Also, for what it's worth, in cryptography, lots of vulnerabilities are considered "theoretical", but really what they mean is that there is such a large work factor involved that exploiting the vulnerability is totally impractical based on current (and sometimes foreseeable future). An example is two related-key attacks on the full-round AES-256 where there is key recovery attack that works for all the keys and has 2**99.5 time and data complexity. Some consider it "theoretical" because it is far beyond the capabilities of current computing powers. But as you have pointed out, these "theoretical" vulnerabilities are very real, it is the the potential of using the vulnerability for a successful exploit that might be considered more "theoretical" and that depends largely on the assumptions of your threat model and especially of your adversaries capabilities. But even calling the exploitability "theoretical" is dangerous. When Serge Vaudenay first wrote about the padding oracle attack on CBC mode in 2002, there were many who wrote off the vulnerability as "theoretical". As a result, many did nothing to address this problem (for example, by using authenticated encryption modes). Then Thai Duong and Juliano Rizzo came along in 2010 with a more practical exploit for a padding oracle attack on CBC mode and all of a sudden we had millions of sites exposed. We were caught unprepared because we disregarded an attack as being impractical. We ignore the truism that "attacks only get better" at our own peril.
Information Security Leader | Application/Product Security
9 年The argument's really 'What makes vulnerability plausible'
Application Security Education Consultant
9 年Bravo! Jeff. Theoretical vulnerabilities? Oh sure, those are the vulnerabilities that are and will be exploited by theoretical assholes.
CEO @ Software Secured - Investor
9 年Agreed. There are no theoretical vulnerabilities. It is either a vulnerability or not. There are vulnerabilities though that require a lot of effort from the attacker in order to be exploited and in this case that should be reflected in the risk (i.e. lower). Agreed also that most static and dynamic security testing tools turns a lot of false positives and there is a lot of room for improvements.