Re: Healing the bash fork

["David A. Wheeler" <dwheeler () dwheeler com>]

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."
  http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/environment-variables.html

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