16

race conditions, etc.

Are there automatic tools for this? What manual techniques should I use?

From the Area51 proposal

Shelvacu
  • 2,333
  • 4
  • 16
  • 29
AviD
  • 72,138
  • 22
  • 136
  • 218

2 Answers2

8

Timing attacks, race condition (CWE-362) vulnerabilities are not very common for web-applications, these are primarily problems of more low-level languages. For example, in CVE-2006-5178, race condition was due to incorrect implementation in PHP interpreter itself. But application relying on those functions goes vulnerable too.

It could be daunting to attempt to reproduce such vulnerability, due to timing issues and the needs of specific environment. With automated vulnerability scanners it is not feasible to conduct such test - even for human it is not easy to find such vulnerability.

To my opinion, developer just needs to keep in mind when the main process can be interrupted. Atomicity should be provided when the sequence of actions must not be interruptible. Mainly database actions are susceptible to such attacks. Even when DBMS supports transactions and provides means for safe synchronization, there can be more global actions that are under control of DBMS to make them atomic. Attention should be pointed also to situations where threads are used.

In the link to CWE-362, there are list of papers that are useful to read. Those would provide much more information than I have given here.

  • 3
    @Ams, I disagree. I have personally seen race conditions in several web apps, and not just in the low-level languages or frameworks. You have to think at a higher level here... For example, how about a banking app, that verifies you have enough in your account before making a transfer. If the check and transfer are not done in a single db transaction, it is *possible* to send 2 requests simultaneously, and transfer out twice as much. Though I definitely agree with you about how hard it is to find... That's why I'm asking for tips and ideas. – AviD Nov 21 '10 at 07:07
  • @AviD, I am not denying the possibility of race conditions in web-apps. Looks like I had to highlight it. When I was speaking about DBMS, I was considering them. –  Nov 21 '10 at 11:09
  • True, but that was just one trivial example. I've seen the same with e.g. session variables, server-side shared application variables, even one (more complicated) on client-side cookies. – AviD Nov 21 '10 at 11:11
  • Sure, the scope of the timing attacks does not ends only with database issues, that's why I wrote "mainly database...". I agree, there are more sophisticated attacks within this vulnerability, I just wanted to note some general points. –  Nov 21 '10 at 11:30
  • 1
    Of course a big challenge I found, even in environments set up to practice this kind of thing was that connectivity lag could hide any timing attacks, so it is a very tricky one to test in anything other than a purpose built, segregated test environment. – Rory Alsop Dec 16 '10 at 14:16
6

The discussion and answers here appear to be around race conditions, which are usually referred to by that name.

If you really mean timing attacks, you're probably talking about information leakage via discrepancies in execution time. A Lesson In Timing Attacks is a nice, accessible introduction to this.

I'm not aware of any tools that could specifically assist in discovering these, but common web assessment tools could reveal other problems that could be exacerbated by a timing attack.

Suppose you have a vulnerability that allows an external party to run SQL code against your database -- classic SQL injection. Suppose you've taken some precautions: they cannot get data back out or write arbitrary information to your database, you just return a generic error message of some sort. It would be possible for the external party to probe the schema of your database using "select" statements and timing how long it took to receive a response; simply by observing how much work your back-end system is doing, they're learning something about it that they may not have otherwise (whether a particular table actually exists, whether there many be many records in a table, etc.).

medina
  • 161
  • 1
  • Actually, *race conditions* are a subset of *timing attacks*. Timing attacks in SQL Injection are another - similar to sidechannel attacks in cryptanalysis. You're right, though - timing attacks **are** more than just race conditions, but that is kinda what the question was about. Unless you have more info on the other attacks... – AviD Dec 18 '10 at 16:08
  • 1
    The most concerning other attacks are timing side-channel attacks on crypto used for authentication - http://lists.openid.net/pipermail/openid-security/2010-July/001160.html and http://rdist.root.org/2010/11/09/blackhat-2010-video-on-remote-timing-attacks/ (warning - includes video) – Bell Mar 02 '11 at 04:36