[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <543412D2.7080106@oracle.com>
Date: Tue, 07 Oct 2014 17:20:34 +0100
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
On 07/10/14 16:45, Michal Zalewski wrote:
>>> What class of bug is Shellshock? "Weird feature invented in
>>> >> pre-Internet era"? How do you conquer this class of bugs?
>> >
>> > There are two bugs: Calling “eval” on untrusted input (a relatively common
>> > issue), and the fact that this particular code path should never have been
>> > exposed to the network at all. The second part is not strictly a bash bug,
>> > even if we addressed that with a change in bash. If this issue had been
>> > discovered when the first CGI-enabled web server was implemented, maybe it
>> > would not have been called a bash bug, but a bug in how CGI used environment
>> > variables.
> Possibly, but it probably wouldn't have stayed that way for long. Even
> though the bug was introduced long before the arrival of Apache, I
> would guess that it had affected Sendmail from day one.
>
> In practice, it's usually counterproductive to try to precisely pin
> the blame; bash is the place where we can fix it more easily and
> produce more intuitive behavior with one less things for other
> developers to worry about it.
In the particular case of shellshock, "everyone knows" that calling eval
on untrusted input is a really bad idea. It's bad in anything that has
an eval mechanism. The problem, still, with bash is that happens
without you having any control over it.
For example,
env 'BASH_FUNC_ls()=() { echo hi there; }' bash -c ls
Obviously that's artificial and the Florian's fix ensures that it's
difficult to trigger remotely. This doesn't mean that the eval over
which you have no control is a good idea.
In this particular case you could argue that any application that could
possibly exec a shell or possibly cross a trust boundary should clean
its environment: we even have a nice easy to recognise pattern (anything
that begins BASH_FUNC_ which also happens to strip out the other two
implementations of the wrapper).
However, I deliberately included "possibly" twice to encompass
practically all non-trivial applications. If you're going to try to pin
a class of bug on shellshock then it's something like "uncontrollable
eval on untrusted input" and bash is still doing this. it's not been
fixed (excepting NetBSD and FreeBSD).
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.
