During the past few days I had the opportunity to talk about security for entire days with amazing and passionate guys. I had a great feeling about the group in which I was, and a great feeling about every single person belonging to that group. During our discussions some folks asked to me very complex questions that I was not able to properly answer because the complexity. So I decided to write a quick'n dirty blog post for every question I think I let opened or partially opened.
Today I 'm going to dig a little bit into Vulnerability Classification.
Historically vulnerabilities have been classified in broad super set such as: buffer overflows, format string vulnerabilities, and integer type range errors (including integer overflows). These broad categories have two major failings, however. First, it is not always possible to assign a vulnerability to a single category. Second, the distinctions are too general to be useful in any detailed engineering analysis.
Quoting an example from: "A structured Approach to Classifying Security Vulnerabilities" (Cert 2005) the following function contains two vulnerabilities.
Len1 or Len2, could be negative -- bypassing the logic of the program -- and both the functions strncpy(..,..,..,) and strncat(..., ..., ...) suffer of buffer overflow. The question raises natural : is this function classificable as an "integer range check" vulnerability or as a "buffer overflows" vulnerability? Can the function be classifcated as both of them ( integer range check vuln and buffer overflow vuln) ? In this last case, do we need to provide "ranges and indicators" to exactly point to the vulnerability offset in order to distinguish the two vulnerability sets? Is this the best approach ? Generally speaking when the "science" classifies something it never split the "classified object" into primitive subst of objects, but contrary it collects as many proprieties as it can from the "classified object" in order to build an unique "signature" able to identify it.
For example if we consider the science of systematics it does not classify a cat into multiple cathegories because has a tail, 4 legs and 2 eyes, but it classifies the cat because his biological composition. Indeed the alligator has a tail 4 legs and 2 eyes but it's obviously different from a cat!
What we need is to switch to taxonomies to be able to classify vulnerabilities in a way to be useful for engineers and enough general to wrap all the known vulns. The Program Analysis (PA) study is one of the first taxonomies approach applied to vulnerabilities classification. Following the RISOS study Matt Bishop in his report: "A Taxonomy of UNIX System and Network Vulnerabilities" described six vulnerabilities classification schemes .
Those graphs show the frequencies of flaws in each of the six classification schemes used in Matt's paper. CERT did a great job in vulnerability taxonomies as well as Anil Bazaz and James D. Arthur did in their paper titled "Towards A Taxonomy of Vulnerabilities". The following image shows a subset of the CERT taxonomy:
According to the CERT taxonomy, four are the main root causes of vulnerabilities: Design errors, Implementation errors, User interface and Other problems. In this picture only a subset of the implementation errors is showed. "Design errors" might relay to absence of designed patterns, "user interface" might relay on weak protection and "other problems" might relay on physical protections and so on..
Vulnerability classification is not an easy "field". It's not enough to say "buffer overflow", " format string" and "integer overflow" anymore -- -- -- to properly classify vulnerabilities. We need to keep in mind that researchers made great taxonomies to make class of vulnerabilities and to help engineers to recognize all the possible available solutions.
