Monthly Archives: October, 2006

Insert a classy pun.

This entry should have been published days ago. On top of being overly busy and spread thin, I ran into a big problem related to finding a reference I wanted to include, which will lead to this being a little more ranty than intended.

How is it that our industry is over twenty years old (don’t bother debating how old the ‘security’ industry really is), and we don’t have a list of commonly accepted vulnerability classifications? Traditionally, it was fairly easy to list out the major classifications; overflow, symlink, race condition, command injection, XSS, SQL injection, path disclosure, traversal, denial of service, format string, etc. Over time we saw new types of vulnerabilities like HTTP Response Splitting, CRLF injection, Off-by-one, Underflows, etc. So, who keeps a list of what constitutes a class of vulnerability? The Secure Software Body of Knowledge has nothing, SANS’ glossary doesn’t even appear to have cross site scripting, and the OWASP Top Ten is a bit too high level. The best resources are probably:

  1. The OWASP Vulnerability Listing but I think this is too detailed to cover a general classification breakdown.
  2. Mitre’s Common Weakness Enumeration (CWE) might be the best due to their hierarchy system and more general categories.
  3. CVE’s Vulnerability Abstraction has a decent breakdown more like my quick list above, but might be considered a bit lacking, or soon will be.
  4. The Web Application Security Consortium Web Security Glossary but it is web-centric.

That said, now I can get back to my original point! On September 29, Stefan Esser posted an advisory in which he said “While searching for applications that are vulnerable to a new class of vulnerabilities inside PHP applications we took a quick look…“. This lead me to remember an article last year titled Microsoft unveils details of software security process in which Window Snyder (former Microsoft security strategist) said “These are entire classes of vulnerabilities that I haven’t seen externally. When they found these, (the developers) went on a mission, found them in all parts of the system, and got rid of them.” referring to vulnerabilities that were proactively removed. The article goes on to say “Moreover, the company found and fixed two classes of vulnerabilities that have not been discovered elsewhere, she said.

Anyone else curious about these? Less than a year, and three new classes of vulnerabilities? Come on Window, you left Microsoft, you can speak up now! Steffan, spill the beans, give us details!

Thanks for discussion and pointers: Steven Christey, Chris Wysopal, Sullo

Google VulnSearch?

Fall behind and someone will always beat you to the punch! Gadi Evron posted an entry over at Securiteam on the topic of using Google’s Codesearch to find vulns. Since he and others are writing about this, I don’t have to! However, i’ll post a few more thoughts before anyone else maybe!

First, we have this great ability to (ab)use Google’s Codesearch to find vulnerabilities through fast code analysis. Is this a fun but very short fad? Or will we see people use this to disclose vulnerabilities and give credit to their method? Will it lead to a lot of false positives> like we’re seeing with remote file inclusion? Several ‘researchers’ are grep’ing for a single stringle, finding it, and posting it as a remote file inclusion vulnerability without really analyzing the code or testing their own “proof of concept”. Hopefully, researchers will use this new tool to not only find vulnerabilities, but truly validate their finding before disclosing.

Second, who is going to be the first to create an interface that smoothly links the Google Codesearch with a robust static code analyzer? Imagine a web interface where you choose a few key things like what language, what types of vulnerabilities, and click click for all the results. The program would then use the Codesearch results to pipe into the code analyzer and spit out a list of high probability vulnerabilities.

Some of these ideas courtesy of email discussions with Chris Wysopal, Mudge and others.

Vulnerability Type Distributions in CVE

Document version: 1.0 Date: October 4, 2006

For the past 5 years, CVE has been tracking the types of errors that lead to publicly reported vulnerabilities, and periodically reporting trends on a limited scale. In support of the Common Weakness Enumeration (CWE) project, and as a result of the interest in this work as mentioned during the “Year of the web application: Hack & Data from the Front lines” panel at the 5th Annual Cyber Security Executive Summit in New York City on September 13, 2006, we have published a more extensive analysis. An updated version will be released once 2006 is complete.

The primary goal of this study is to better understand research trends using publicly reported vulnerabilities. It should be noted that the data is obtained from an uncontrolled population, i.e., decentralized public reports from a research community with diverse goals and interests, with an equally diverse set of vendors and developers. More specialized, exhaustive, and repeatable methods could be devised to evaluate software security. But until such methods reach maturity and widespread acceptance, the overall state of software security can be viewed through the lens of public reports.