Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Thursday September 25 2014, @01:59AM   Printer-friendly
from the well,-that's-not-ideal dept.

Ars reports that a new bug has been found in GNU Bash allows remote attackers to execute arbitrary code by setting the process trailing strings after function definitions in the values of environment variables.

This bug is reported to be present in RHEL (ver 4 through 7), Fedora, CentOS (ver 5 through 7), Ubuntu (ver 10.04 LTS, 12.04 LTS, and 14.04 LTS), Debian, and even OS X Mavericks.

This bug is exploitable through Apache servers with mod_cgi and mod_cgid loaded, OpenSSH, malicious DHCP servers in a compromised wireless access point through dhclient, as well as the CUPS printing system.

The Ars also includes a simple single liner that will test your setup for the newly found discovery:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

A vulnerable system will output the following:

vulnerable
 this is a test

While a patched or unaffected system outputs:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

A patch is already out, so administrators are advised to update Bash.

Editor's Update: Security Engineer Tavis Ormandy has said "The bash patch seems incomplete to me, function parsing is still brittle".

$ env X='() { (a)=>\' sh -c "echo date"; cat echo

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by frojack on Thursday September 25 2014, @01:20AM

    by frojack (1554) on Thursday September 25 2014, @01:20AM (#97999) Journal

    This bug is reported to be present in RHEL (ver 4 through 7), Fedora, CentOS (ver 5 through 7), Ubuntu (ver 10.04 LTS, 12.04 LTS, and 14.04 LTS), Debian, and even OS X Mavericks.

    As well as every version of Opensuse SLED, SLES, OpenBSD, NetBSD.

    EARLY patches are still said to be problematic "brittle" was the word used.

    --
    No, you are mistaken. I've always had this sig.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Informative) by SNK on Thursday September 25 2014, @07:50AM

    by SNK (243) on Thursday September 25 2014, @07:50AM (#98128)

    The default installations of FreeBSD/OpenBSD/NetBSD are not affected, since they do not include bash.

    • (Score: 2) by frojack on Thursday September 25 2014, @06:33PM

      by frojack (1554) on Thursday September 25 2014, @06:33PM (#98351) Journal

      The default installations of FreeBSD/OpenBSD/NetBSD are not affected, since they do not include bash.

      Not sure I believe that, because bash is on my openbsd 5.5 system. I might have put it there explicitly, but I don't recall doing that.

      But if you have bash installed on openbsd it is STILL vulnerable today, and no patch seems to be available.
      On NetBSD, where it is also commonly installed, it has been fixed as of this morning.

      --
      No, you are mistaken. I've always had this sig.
      • (Score: 1) by SNK on Friday September 26 2014, @08:12AM

        by SNK (243) on Friday September 26 2014, @08:12AM (#98514)

        If not installed explicitly, then bash was probably installed as a dependency for another port.

        You are right that *BSD is affected if bash is installed. However, the attack vector is different, since /bin/sh never links to /bin/bash, and bash is not installed by default.

        • (Score: 2) by fnj on Friday September 26 2014, @09:31AM

          by fnj (1654) on Friday September 26 2014, @09:31AM (#98522)

          So the attack is pretty irrelevant to BSD, isn't it? Even if bash is installed, system() and popen() and dhclient are never going to call it. They call /bin/sh. The same goes for debian and ubuntu, where /bin/sh is symlinked to dash, not bash.

          Sloppy system design counts (I'm looking at you, Redhat and Suse and lots of other distros, with your /bin/sh syml;inked to bash).

      • (Score: 2) by fnj on Friday September 26 2014, @09:18AM

        by fnj (1654) on Friday September 26 2014, @09:18AM (#98519)

        It doesn't matter whether you believe it or not. It's true.

        Now, as to BSD systems where you install bash. It still doesn't make /bin/sh a symlink to bash, like most linux distros do - a sloppy, brain dead practice. So as far as I know, even if bash is installed, BSD is not sysceptible to the exploit as it is explained.

        P.S., debian doesn't have /bin/sh symlinked to bash either. It symlinks it to dash. I don't believe dash has the bug. At least it passes the test scripts I've tried. You have to modify the stupid test scripts to run /bin/sh, not bash. After all, that's what system() runs: /bin/sh, not bash. So as far as I can tell, debian is OK, too.