[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54340E5A.1060600@redhat.com>
Date: Tue, 07 Oct 2014 18:01:30 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
On 10/07/2014 05:45 PM, 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.
I suspect sendmail had to run on systems where setenv was not even
remotely binary-transparent.
> 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.
Absolutely agreed. It was possible to fix in bash in a relatively clean
way (certainly cleaner than in the kernel or glibc), so we fixed it
there. I don't see this kind of analysis as putting the blame—we need
to investigate vulnerabilities and see if there are any ways to squash
large classes of bugs. Not sure if there is anything that would work
here (you can rewrite the shell in SPARK, prove it correct, and still
have the bug). But it's still a topic worth exploring in general.
--
Florian Weimer / Red Hat Product Security
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.
