Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 15:50:06 +0100
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: Healing the bash fork


On 30 Sep 2014, at 15:07, Sebastian Krahmer <krahmer@...e.de> wrote:

> In no shell-universe
> 
> setreuid(0, 0); system("date");
> 
> is an "innocuous looking setuid program". It fails in so many ways
> that I cant enumerate it here, despite missing sanity checks for readability
> and in that suids must not use system() or popen() in the first place.
> 
> If one finds a construct in code that looks similar to this, fix it. Really.
> No bash update (and no other shell) will ever make this secure. If we start
> fixing the underlying system so that above code is innocuous indeed, rather
> than fixing the programmers producing such code, our road ends at php.

It’s not about making that secure. Suppose, for example, that your program here is one of those many that have helper shell scripts.   Find one that has a vector where you can insert things into an ancestor’s environment.   Find an interesting vulnerability in a deeply embedded shell script and …. profit.

You can argue  that those programs and shell scripts shouldn’t be vulnerable, but you have locks on your car doors even though you have an intruder alarm and an immobiliser.

jch

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.