2014-10-09 21:35:09 -0400, Chet Ramey: > On 10/9/14, 6:06 PM, Pádraig Brady wrote: > > On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote: > >> Hello Chet, > >> > >> Re: testing for Shellshock... would like your feedback... specifically, > >> regarding the possibility of human-directed combinatorial testing to find > >> this Bash vulnerability... > > > > Sounds like how Michal Zalewski found the related CVE-2014-6278 > > http://lcamtuf.blogspot.ie/2014/10/bash-bug-how-we-finally-cracked.html > > That's a promising approach. I asked Michal to continue running the fuzzer > against the patched, but he did not respond to that yet. [...]
What's the point? That would be wasted effort IMO. Who cares if bash does something unexpected on incorrect input as long as it's not exploitable? The problem here was bash interpreting untrusted input. That has been fixed by stopping the parser from being exposed to untrusted input. Now bugs in the parser are only relevant if they affect functionality, that is, bash behaving the wrong way on valid input (code) and fuzzers are not likely to help much there. From that point of view, all the CVEs related to shellshock are non-bugs or very insignificant ones once the parser is no longer exposed. >From a security point of view, there are things in bash and other shells that are far more inportant to look at than what it does on incorrect code: when it deals with other forms of untrusted input. One thing for instance and that also affects some other shells are like: bash -c '(( XDG_VTNR < 7 )) That allows arbitrary code execution (and can't easily be fixed without breaking backward compatibility). Try with "export XDG_VTNR='a[$(echo>&2 vulnerable)]'". How do you fuzz-test for that? You can't really until you've identified the problem already (that the arithmetic parsing has side effects (here expands cmdsubst inside arrays, but XFG_VTNR='PATH=1' could be as much of a problem). Without breaking backward compatibility, the best way to address it is document it: always sanitize external input before using them in arithmetic context. -- Stephane