Re: [Help-bash] bash vulnerbility

[Eric Blake]

On 09/25/2014 10:31 AM, Bryan Luoma wrote:
> Hello,
> 
> Can you provide a brief update about the recent bash shell vulnerability?
> 

The problem at hand is that bash used regular shell variable names in
the environment for implementing its ability to export shell functions
to child shells.  Because it is not munged in any way, this
implementation collides with ANY environment variable where a user can
supply an arbitrary string.  Worse, there are several well-known
programs that do just that (for example, apache uses environment
variables with user-controlled content to spawn cgi scripts.  If a
vulnerable bash child process starts with such an environment variable,
it basically does 'eval' on the value of that variable to reinstate the
function definition.  Normally, 'eval' of a function definition has no
other impact than adding a function into bash's memory, but if the
string is not a function definition but something else, it is now up to
your imagination what you can do (define a shell variable that looks
like both a function definition and another command - CVE-2014-6271;
define a shell variable that has a shell syntax error that overlaps
where the current bash parser has bugs, such that the syntax error
allows you to access out-of-bounds memory and do whatever you want with
a convoluted enough string - CVE-2014-7169).  Vulnerable bash processes
parse their environment variables on startup, prior to anything your
shell script can do.  Furthermore, since functions are normally not in
the same space as shell variables except for this initial parse, there
is no way for a shell script to easily tell if a bogus environment
variable was passed in (by the time the shell script is running, bash
has already parsed the bogus variable as a function).

> Which specific versions of gnu bash does it affect?

ALL unpatched versions, at least back to 1.14.0 (shipped in 1994, the
oldest tarball available on gnu's ftp site).  Official patches are
available back to 3.0 on the bug-bash mailing list and ftp site, and on
other mailing lists, Chet has even offered to backport the patch to
people still using 2.05b.  If you use a distro, your distro has probably
already been providing patched versions as fast as they are made
available, so upgrade your system in accordance with your
distro-recommended practices.

> Any other details (patching, etc..) appreciated.

Applying the latest official patch for your base version (such as
ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025) will solve
CVE-2014-6271 (Shell Shock, part 1, arbitrary remote execution), but
will not solve CVE-2014-7169 (Shell Shock, part 2, limited remote
execution).  Patches are being actively discussed, and another round of
official patches will be issued as soon as people agree that we aren't
leaving yet more holes in the situation.  If you are debating between
delaying your fix to get both CVEs fixed in one update, vs. plugging a
hole now then having to repeat the process later, I recommend plugging
6271 now rather than waiting, as the hole from 6271 is so much easier to
exploit and is so severe in what exploits it trivially allows, while the
hole from 7169 is less severe in terms of security exploits.

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
is also a good read.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature