[OpenIndiana-discuss] Bash bug issue

[Bayard Bell]

These aren't new aspects of the bug. The fact is that default operation of
systems using bash as the shell for interpolation with system or for
scripts interpreted by bash allows remote code execution by taking strings
from untrusted sources (e.g. USER_AGENT in web servers) and passing them
through the environment, which allows remote code execution. What you're
reporting here is instances of the resulting problem in products matching
this description, not fundamental changes to the understanding of the bug.

What's been difficult is that Red Hat's security response team and bash
upstream initially differed on the scope of the issue and thus patching, as
Red Hat believed there were broader problems and that upstream patches were
therefore too limited in scope. Red Hat was subsequently shown to be
correct.

The confusion is that there are a number of CVEs out there, and the patches
went out in batches. There are quite a variety of tests proposed for the
fully documented CVEs, and some of the CVEs remain embargoed, with Red Hat
simply advising that people take patches which bash upstream subsequently
accepted.

On 6 October 2014 18:58, The Outsider <openindiana at out-side.nl> wrote:

> Search q-nap & shellshock and you see how deep this goes...
>
>
> On 6 oktober 2014 19:28:00 David Brodbeck <brodbd at uw.edu> wrote:
>
>  On Thu, Oct 2, 2014 at 8:12 AM, Alan Coopersmith <
>> alan.coopersmith at oracle.com> wrote:
>>
>> > On 10/ 2/14 07:00 AM, Brandon Hume wrote:
>> >
>> >> On many (most?  all?) Linuxes, /bin/sh *is* /bin/bash.
>> >>
>> >
>> > Many, but not all - the Debian family and some others use a lighter
>> weight,
>> > POSIX compatible shell instead, dash, the Debian Almquist Shell; and
>> many
>> > embedded distros use BusyBox instead.
>> >
>> > https://en.wikipedia.org/wiki/Almquist_shell
>> > http://lwn.net/Articles/343924/
>>
>>
>>
>> A big driver of this was faster boot, since boot scripts run on /bin/sh.
>> On some systems the startup time for all those bash processes was a
>> considerable portion of the total boot time.
>>
>> Note: It's not enough to make sure no CGI scripts are being run with
>> /bin/bash.  You also need to make sure no bash processes are being
>> launched
>> by other scripts, since many scripting languages launch a shell to run
>> external commands.  Unless the environment is explicitly cleared these are
>> likely to inherit the environment of the calling process, with all the
>> nasties in it.
>>
>> --
>> D. Brodbeck
>> System Administrator, Linguistics
>> University of Washington
>> GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>
>
>
>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>