[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Healing the bash fork
From:       Michal Zalewski <lcamtuf () coredump ! cx>
Date:       2014-09-30 23:59:56
Message-ID: CALx_OUCv6bfPd_r3fNAJC=gjvNp0kt0H9RBp3o9tN0ZShBNh4Q () mail ! gmail ! com
[Download RAW message or body]

> Finally: *PLEASE* let me know if you have any good ideas on how to find v=
ulnerabilities like this ahead-of-time. My article "How to Prevent the Next=
 Hearbleed" (http://www.dwheeler.com/essays/heartbleed.html) lists a number=
 of ways that Heartbleed-like vulnerabilities could have been detected ahea=
d-of-time, in ways that are general enough to be useful.  I'd like to do th=
e same with Shellshock, so we can quickly eliminate a whole class of proble=
ms.

Well, hindsight is always 20/20. Manual audits and fuzzing would have
had a good likelihood of spotting the bash flaw. In fact, I used a
fairly generic fuzzer to quickly hit three of the four previously
disclosed issues and identify two more. The syntax is terse and the
parser is laid back, which helps. The fault conditions are generic and
intuitive, too - creation of a file, execution of a child process, or
a crash.

But really - all it would have taken is just somebody with un*x
security background reading a book on bash that mentions function
exports (I'm sure there are some); it wouldn't be hard to connect the
dots.

The main problem is that for a very long time, we apparently had no
overlap between these groups. At the face of it, it seemed like
there's absolutely no reason for bash to try to parse generic env
variables. With no convincing reason to study or test the code, nobody
did.

/mz
[prev in list] [next in list] [prev in thread] [next in thread]