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

[Chet Ramey]

On 10/10/14, 5:40 AM, Stephane Chazelas wrote:
> 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.

It depends on your goals.

> Who cares if bash does something unexpected on incorrect input as
> long as it's not exploitable?

I do, if it can cause a crash.

> 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.

I agree that the important thing is that the parser isn't exposed in
the way it was, and that the reports post-patch 27 are simple shell
bugs.  However, I'm interested in shell bugs.

> 
> 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)]'".

Sure, and that's documented, intended, and not unique.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/