oss-security - Re: Fwd: Non-upstream patches for bash

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 27 Sep 2014 01:56:49 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Fwd: Non-upstream patches for bash

On Thu, Sep 25, 2014 at 11:37:12PM +0530, Huzaifa Sidhpurwala wrote:
> On 09/25/2014 11:26 PM, Solar Designer wrote:
> >What's the oldest version of bash affected by them?
> >
> >Your reproducers didn't trigger any obvious misbehavior here with 3.1.8
> >with lots of unrelated patches.  Of course, this does not mean much, but
> >maybe these issues are in fact 3.2+?
> 
> Yes 3.2+, i have not checked older versions though.

I took a look at the code in 3.1, and it looked just as vulnerable.  So
I tried harder, and was able to trigger both issues that you're patching
with parser-oob-3.2.patch on 3.1.

For the redir_stack issue, I had to use many more <<EOF's, and I
actually closed those EOF's.  In fact, I used 1000 of them (both opening
and closing).  This gave me a segfault.

For the nested blocks (for loops in this case), I also used as many as
1000 of them, and got this:

$ bash test-script.sh 
test-script.sh: line 909: syntax error near unexpected token `newline'
test-script.sh: line 909: `for x909 in ; do :'

And this remains exactly line 909 when I try 909, 1000, or 2000 nested
loops.  With "only" 908 nested loops, this symptom goes away - but I
guess those 908 loops are not actually processed correctly, see below.

So I guess it's just my (un)lucky memory layout within the bash process
that requires more of these things to trigger visible misbehavior.

Regarding the nested blocks patch:

     case CASE:
     case SELECT:
     case FOR:
-      if (word_top < MAX_CASE_NEST)
+      if (word_top + 1 < MAX_CASE_NEST)
        word_top++;
       word_lineno[word_top] = line_number;
       break;

I think it's sweeping the remaining problem under the rug.  It will not
result in correct handling of arbitrarily many nested blocks, nor in a
proper error message.  It merely prevents the out-of-bounds access here.

Luckily, these shouldn't be security issues anymore once we prevent the
parsers from being exposed to untrusted input.

Alexander

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.