Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

[Stephane Chazelas]

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