Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 06 Oct 2014 15:14:35 -0400 (EDT)
From: "David A. Wheeler" <>
To: "oss-security" <>
Subject: Re: Healing the bash fork

On 09/30/2014 05:02 PM, Mark R Bannister wrote:
> > Glad my over-simplified example has raised a few smirks.  Now for a slightly less simplified version:
> > putenv("PATH=/bin:/usr/bin");
> > setreuid(0, 0);
> > system("date");
> > But the point is I've tried to boil down a relatively complex program by studying endless strace outputs to attempt to demonstrate a real world exploit.  It wasn't actually "date" that was being called, but you get the point.
> > In the past, i.e. pre-Shellshock, the above code may have raised eyebrows, but as PATH was sanitised it would have passed numerous security audits.

People do all sorts of things they shouldn't.  But it's been well-publicized that they should NOT just set an environment variable when crossing a trust boundary (e.g., setuid/setgid).  I'll note that my freely-available book, which has been available for years, says:
"For secure setuid/setgid programs, the short list of environment variables needed as input (if any) should be carefully extracted. Then the entire environment should be erased, followed by resetting a small set of necessary environment variables to safe values."

The problem with shellshock is that bash would respond to *any* environment variable.  Attacker-supplied data *has* to sendable to a program that checks it (e.g., for CGI). What's more, no trust boundary had to be crossed in this case.  Thus, extract-and-erase made no sense in that context.

--- David A. Wheeler

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.