Date: Tue, 30 Sep 2014 16:59:56 -0700 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: Healing the bash fork > Finally: *PLEASE* let me know if you have any good ideas on how to find vulnerabilities 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 ahead-of-time, in ways that are general enough to be useful. I'd like to do the same with Shellshock, so we can quickly eliminate a whole class of problems. 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
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.