A remotely exploitable hole in bash

Posted Sep 26, 2014 8:46 UTC (Fri) by sitaram (guest, #5959)
Parent article: A remotely exploitable hole in bash

I took David Wheeler's quote to heart and added one more layer of indirection while the big boys figure out what is the correct patch.

Copy /bin/bash to /bin/oldbash, put this script in as /bin/bash, and fix up permissions:

    #!/usr/bin/perl
    # env safe bash
    use strict;
    use warnings;

    for (keys %ENV) {
        delete $ENV{$_} if $ENV{$_} =~ /^\s*\(\s*\)\s*\{/;
    }
    exec "/bin/oldbash", @ARGV;

(Log in to post comments)

A remotely exploitable hole in bash

Posted Sep 26, 2014 16:35 UTC (Fri) by cesarb (subscriber, #6266) [Link]

That regexp seems underconstrained. From what I've read, the condition to trigger the vulnerability is the precise four characters "() {" at the beginning of the environment variable; any extra whitespace and bash treats it as a normal environment variable.

So it should probably be (untested): /^\(\) \{/.

A remotely exploitable hole in bash

Posted Sep 26, 2014 23:04 UTC (Fri) by sitaram (guest, #5959) [Link]

Yes it's blocking more than needed, but I don't see any of the needlessly blocked variants as being useful in real life so it doesn't matter.

A remotely exploitable hole in bash

Posted Sep 29, 2014 11:08 UTC (Mon) by k8to (guest, #15413) [Link]

good thing you're on a platform that supports unsetenv :-D

A remotely exploitable hole in bash

Posted Sep 29, 2014 17:05 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> …a decent unsetenv.

FTFY :) . Apparently some implementations just unset the first instance of the variable in the environment, not all of them.

A remotely exploitable hole in bash

Posted Oct 5, 2014 4:39 UTC (Sun) by k8to (guest, #15413) [Link]

Yeah I was thinking of AIX where there is no unsetenv.