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]
Message-ID: <11352F9641010A418AD5057945A3A6594CBFBE@MTV-EXCHANGE.microfocus.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ