Vulnerability Description Languages and Classifications - Empirical Validation of Muffett's Second Law?

Way back when - at least 8 years ago, by my recollection - my pal Alec posted the first disclosure of "Muffett's Second Law", which states:

"There are no new security bugs, there are merely ever-more-complex reincarnations of the same classes of bug."

While this appears to fly in the face of a huge plethora of vulnerability disclosures at first sight, there's method behind this. Consider the ways in which vulnerabilities can readily be grouped:

  • stack or heap overflows / smashes
  • connection source spoofing
  • cache poisoning
  • dictionary attacks
  • data injection into existing sessions
  • session replay
  • introduction of "unexpected" data (eg numbers outside expected ranges, strings of greater than expected length)
  • reference rewriting (whether to force or block branches within self-contained code or to perpetrate cross-site scripting attacks...)
...these attack mechanisms appear to have remained pretty invariant in terms of concepts - although the means of implementation have shifted - over the time I've been professionally involved in computing.

The fact that a vulnerability description language has emerged to handle structured vulnerability disclosures, and a dictionary of terms is being compiled to assist with consistency of same, suggests that this particular Muffett's Law has a good degree of truth behind it...

Comments:

incidentally: cache poisoning == data injection into existing sessions strings of greater than expected length == stack overflows (typically)

Posted by alecm on March 19, 2007 at 10:26 AM GMT #

Typically, yes, but not always. The "nscd with nonzero TTL" issue which used to exist, whereby DNS resolution results could be injected without being apropos of a DNS lookup request, is such an example.

Or, putting it another way, what set of categories would you use to classify vulnerabilities?

Posted by Dave Walker on March 19, 2007 at 11:38 AM GMT #

>Or, putting it another way, what set of categories would you use to classify vulnerabilities? That's a very good question. I don't think I have decided yet, having spent several years on and off, thinking about the topic. The "poison the DNS cache in advance" attack you cite, for instance; is that preloading information into a soon-to-be-established connection, or is that "spoofing"? It's easy to tie yourself up in fairly pointless knots, worrying about that sort of thing. The notion of describing attacks with XML is cute but in the end will be fruitless. We don't need taxonomy to understand security bugs. We need better code and architecture to avoid them. You can make laws, and identify, measure and label exploits all you want, but in cyberspace the better solution is to warp the universe so that exploitation is not possible. My personal categories? I think I have got it down to between 2 and 5, plus a meta Excess of Privilege Overflow of Bounds (possibly == Excess of Privilege) Loss of Secret (possibly == Excess of Privilege) Blithe Trust Incorrect Information (spoofing, bad creds, cache poisoning; possibly == Blithe Trust) Improper Protocol (implementation artifact leading to one of the above)

Posted by alecm on March 20, 2007 at 04:51 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

davew

Search

Archives
« July 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Today