full-disclosure - RE: [VulnWatch] Re: Concurrency-related vulnerabilities in browsers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Thu, 17 Aug 2006 13:09:13 -0700
From: "Michael Wojcik" <Michael.Wojcik@...rofocus.com>
To: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>,
	<vulnwatch@...nwatch.org>
Cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: RE: [VulnWatch] Re: Concurrency-related
	vulnerabilities in browsers - expect problems

> From: Steven M. Christey [mailto:coley@...us.mitre.org] 
> 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/