Wednesday, 11 July 2012

Are Race Conditions the New Buffer Overflows?

« PCI DSS 2.0 Support Handles Change from Best Practices to Requirement | Main | Presenting “Code Reviewing Web App Framework Based Applications” at Blackhat »

Way back in 2005 we worked with Gary McGraw to develop the Seven Pernicious Kingdoms -- an open taxonomy of software security errors -- that has been adopted by HP Fortify solutions ever since. At that time, we predicted that the Time and State kingdom would become one of the most prevalent classes of errors in coming years. The errors covered by this kingdom are those that result from unexpected interactions between threads, processes, time, and data and include issues such as deadlocks and race conditions. As applications have become increasingly complex and distributed, components must often share state in order to communicate with one another, which has led to a growing number of problems.

It seems that we were not far from the truth. With the widespread adoption of Web 2.0 technologies and a lengthy list of web frameworks, asynchronous execution and keeping track of state have become key features of modern applications. The use of asynchronous communication seems to inevitably lead to race conditions.

Our hypothesis is also supported by the amount of research interest recently given to the topics related to time and state. If you look through the list of papers accepted to the most prestigious programming languages conference PLDI 2012, you will notice that there are a number of papers on such topics as concurrency, thread safety, and parallelization – all of which are directly related to time and state. One of the papers -- Race Detection for Web Applications -- looks especially interesting to us. The paper distinguishes between four different types of races:

  1. Standard data races on JavaScript memory locations,
  2. HTML races,
  3. function races, and
  4. event dispatch races.
The paper also defines the "happens-before" relation and a data access model, and describes a dynamic race detector tool built on top of WebKit. The authors used the tool on 100 real-world websites and found a number of real race conditions that result in runtime exceptions and crashes, so the results are quite promising.

While detecting time and state issues statically is definitely a challenge, doing so at runtime seems to have a lot more potential and opens up the field for more research opportunities with respect to both discovery and detection of time and state vulnerabilities. Let's see if the trend we predicted seven years ago will continue. I think it will.

Posted by yoneil at 10:09 AM in Fortify

 

[Trackback URL for this entry]