> From: Steven M. Christey [mailto:coley@xxxxxxxxxxxxxxx] > Sent: Thursday, 17 August, 2006 14:05 > > [Re Michal Zalewski's recent publications of concurrency issues in > browsers] > > Some interesting work. > > For those who haven't made the connection yet - concurrency issues > probably go far beyond just web browsers. It's a safe bet that *any* > software that's multi-threaded, multi-process, event-based, or > asynchronous could have these sorts of issues. Of course, we already knew that software often has race conditions, and that race conditions are often exploitable vulnerabilities - TOCTOU attacks amply demonstrate that, as do many protocol-injection attacks, and so on. That's not to say that Michal Zalewski's latest isn't Good Stuff; this does indeed look like a whopping class of vulnerabilities that I, at least, hadn't seen discussed substantially before. And as usual he's providing a solid investigation to back up the theory. But I hope most practitioners aren't surprised that race conditions are a security issue in concurrent processing, at least now that it's been pointed out. > Traditional data > manipulation techniques probably won't be effective in finding them. And neither will most traditional forms of testing, such as unit tests and code-coverage testing, since those generally create - even rely on - very deterministic operating conditions. Fuzz testing with multiple input channels (eg multiple conversations, for network applications) fuzzed simultaneously and stress testing will catch some issues, particularly when run on SMP systems. (Of course testing concurrent software on SMP systems is a time-honored, if rather informal, way to shake out some concurrency bugs.) It's my feeling, though, that nontrivial concurrent software written without benefit of formal or automated race-condition detection will always have concurrency issues. Concurrency leads to a combinatorial explosion of program states. That's impossible to test exhaustively, or indeed more than cursorially; and it's impossible for developers to track. The techniques we already use in popular languages for managing concurrency, such as explicit exclusive control of shared resources, help, but they leave far too much to some of the least reliable parts of the system - the coder's attention, memory, and imagination. -- Michael Wojcik Principal Software Systems Developer, Micro Focus
