Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date:  Tue, 30 Sep 2014 16:02:24 +0100
From: "Mark R Bannister" <mark@...seconsulting.co.uk>
To: oss-security@...ts.openwall.com
Subject: Re: Healing the bash fork

> > 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");

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.

If /bin/sh were anything but bash, this would not be exploitable.  However, and even with the latest Shellshock patches available to us today, this remains exploitable on Red Hat, or on any system where the system shell is bash.

That is why this must remain a bash issue, and bash should be fixed to prevent it, and why I've asked for a new CVE to track this.

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.