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 PizzaRollPlinkett on Thursday September 25 2014, @02:43PM

    by PizzaRollPlinkett (4512) on Thursday September 25 2014, @02:43PM (#98250)

    How bad could a bash bug really be? The Internet echo chamber acts like this is the next apocalypse, worse than all the other headline-grabbing Internet issues rolled together. But ... bash? If someone can get a shell, your machine is probably compromised. And are there really any public-facing CGI programs written in bash these days? Even if this was never patched, how bad could it possibly be? I would put this slightly below "you already need root to exploit this bug" Linux issues on the severity scale.

    Are people really using old CGI scripts these days? Written in bash?

    --
    (E-mail me if you want a pizza roll!)
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by choose another one on Thursday September 25 2014, @03:53PM

    by choose another one (515) Subscriber Badge on Thursday September 25 2014, @03:53PM (#98284)

    > Are people really using old CGI scripts these days? Written in bash?

    Apparently cPanel. Don't think anyone uses that much these days though...

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

      by PizzaRollPlinkett (4512) on Thursday September 25 2014, @04:33PM (#98303)

      Even if cpanel uses bash (I have no idea), something like that wouldn't be available to the public, would it? It's a server admin tool.

      Ars just published this:

      http://arstechnica.com/security/2014/09/concern-over-bash-vulnerability-grows-as-exploit-reported-in-the-wild/ [arstechnica.com]

      I just can't get a grasp of how serious this is yet.

      --
      (E-mail me if you want a pizza roll!)
      • (Score: 2) by urza9814 on Thursday September 25 2014, @05:50PM

        by urza9814 (3954) on Thursday September 25 2014, @05:50PM (#98339) Journal

        Even if cpanel uses bash (I have no idea), something like that wouldn't be available to the public, would it? It's a server admin tool.

        It's been many years since I've seen cPanel, but when I did it was always on shared hosing. Mostly resellers, who would buy a couple server instances somewhere and sell them off to hundreds of users. Which means if you can use this through cPanel, then one user possibly use this to take full control of that server, or break into anyone else's account, right?

        • (Score: 2) by choose another one on Thursday September 25 2014, @06:17PM

          by choose another one (515) Subscriber Badge on Thursday September 25 2014, @06:17PM (#98347)

          Yep, take control of the shared hosting server. Once that's done, inject malware into all the sites it hosts, or just use it as part of a botnet, take your pick.

  • (Score: 1) by nishi.b on Thursday September 25 2014, @10:03PM

    by nishi.b (4243) on Thursday September 25 2014, @10:03PM (#98415)

    From what I understood, it is not necessary to have a bash shell at your disposal to trigger this.
    Here is the example I read :
    - a server runs Apache with CGI
    - it uses a CGI module (a perl program, a C program, java, whatever)
    - the URL parameters are transmitted to the program by Apache as environnement variables
    - let's say your CGI calls an external command, such as system("echo >> > /myCounter.txt")
    - An attacker goes to "http://site.com/script.cgi" and sets its "referrer" string to a bash function definition
    - Your CGI script is executed, and runs the external command. This opens up a shell (bash) to run the provided command in the same environment, and *the env variables are interpreted by bash*.
    - This means that any CGI that uses a system() command for example (so executes a bash shell) can be used to run arbitrary commands on the server.

    I am not sure what happens with SSH, but I think it works like this :
    you can define env vars before running ssh to connect to a server, and SSH will try to copy the variables to the shell on the remote host (for example, to keep your language settings). If the shell is bash, the code in the vars will be executed even if the user does not type any command in his shell window.