Re: Healing the bash fork

[Zach Wikholm <zwikholm () cari net>]

Hey everybody,

I don't think I've ever actually written to the list, but we also haven't ever encountered a bug like this. 

Personally, I think a bullet point list (or whatever people use these days) is needed of what all is actually wrong, 
what is broken and how we as a community can assist is desperately needed. Last time I checked there are a total of 6 
CVEs currently assigned to bash related vulnerabilities and I'm sure there are more to come.  

 If there is one already, I apologize in advance. 

Zach W.
________________________________________
From: Ed Prevost <me () edwardprevost info>
Sent: Tuesday, September 30, 2014 8:31 AM
To: oss-security () lists openwall com
Subject: Re: [oss-security] Healing the bash fork

On 9/30/2014 8:08 AM, Tavis Ormandy wrote:
> On Tue, Sep 30, 2014 at 8:02 AM, Mark R Bannister
> <mark () proseconsulting co uk> wrote:
> > > > Florian's prefix/suffix patch is not going to protect against the setuid/setgid exploit that I reported to this 
> > > > list last week.> >
> > > > I discuss the setuid/setgid vulnerability at the following site, including demonstrating how Florian's 
> > > > prefix/suffix patch provides no protection:
> > > >
> > > > http://technicalprose.blogspot.co.uk/2014/09/shellshock-bug-third-vulnerability.html
> > > You do realize that your setuid program is patently unsafe, right? Say:
> > >
> > > $ echo -e '#!/bin/sh\necho pwn3d' >date;chmod 755 date;PATH=.:$PWD
> > > ../setuid_program
> > > pwn3d
> > 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");
> Keep going, eventually you're going to have to stop blacklisting
> variables and use execve ;-)
>
> $ env SHELLOPTS=xtrace PS4='$(id)' ./foo
>
>
> > 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.
> Yes, but it's not safe to use system() or popen() from setuid
> programs, no bash patch is going to change that. In fact, bash already
> does more than most other shells by dropping privileges if euid !=
> uid, i.e. "privileged mode".
>
> > 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.
> No, it's not safe to use system() or popen() in this context.
>
> Tavis.
I believe the term following this is 'Mansplained'