Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

Post reply on HN
Print view View original

191–200 of 432 posts

Re: CVE-2014-6271: Remote code execution through bash

#191

Post by phs2501 »

peterwwillis wrote: post #169

Know what isn't vulnerable to this? Perl CGI scripts with taint mode enabled. http://perldoc.perl.org/perlsec.html#Taint-mode You may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, locale information (see perllocale), results of certain system calls (readdir(), readlink(), the variable of shmre…

Not true if the perl script calls out to bash (i.e. via system), as it doesn't sanitize the environment:

    $ env x='() { :;}; echo vulnerable' perl -T -e "\$ENV{PATH} = '/bin'; system('ls | cat');"  
    sh: warning: x: ignoring function definition attempt
    sh: error importing function definition for `x'
    ...

Re: CVE-2014-6271: Remote code execution through bash

#192

Post by nknighthb »

nitrogen wrote: post #154
nknighthb wrote: post #141

Earlier quoted context omitted.

Are you certain God doesn't exist? This is far from the first environment variable attack to impact CGI scripts, and CGI's successors have avoided passing data in environment variables. It's possible some moron decided to create their own CGI replacement using environment variables, but it's not going to be in widespread use.

How does nginx pass data to passenger? Edit: also note that CUPS is vulnerable according to https://access.redhat.com/articles/1200223 Also dhclient (!)

If you're using the nginx module, it gets the data from an instance of ngx_http_request_t. From there it gets passed around over sockets. Environment variables are not involved.

Using environment variables for request data would be quite insane when one of your marketing strategies is "fast" -- you'd either have to fork-per-connection just like CGI, or pre-fork processes that take input over a socket, deliberately deserialize it into the environment(!), and use getenv.

However overhyped Passenger might be, I don't know why you'd think the Phusion guys are that crazy.

Discovering that CUPS and dhclient may be vulnerable doesn't change anything. I'm talking about HTTP as an attack vector.

Re: CVE-2014-6271: Remote code execution through bash

#193

Post by Sanddancer »

Can someone with mod_security test a regex I wrote that should mitigate this? /\(.?\)\s\{.?\}\s\;/ from testing seems to catch any variants that I can think of that can trigger this bug, but I don't have a machine easily available to me at the moment to test with, unfortunately.

Re: CVE-2014-6271: Remote code execution through bash

#194

Post by dbbolton »

pjungwir wrote: post #138
sauere wrote: post #116

Earlier quoted context omitted.

> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server? Yes. Patch is out.

It appears that Linode changes /etc/apt/sources.list to point to their own mirror of Ubuntu repositories, and as far as I can tell those are not updated yet. So I guess the solution is to wait or edit sources.list. Just FYI if you're on their systems!

Or just manually install the new version with dpkg.

Re: CVE-2014-6271: Remote code execution through bash

#196

Post by teach »

traviscj wrote: post #182
teach wrote: post #161

Earlier quoted context omitted.

Just did an update on my Linode and one of the updates was replace bash 4.1-2ubuntu3 So seems like it's there now.

Depends on whether you have mirrors.linode.com or the ubuntu servers set up in sources.list. I had to swap mine out.

Well, I didn't even know about mirrors.linode.com. Mine were still the ubuntu default servers.

I guess apt-get from one of Linode's mirrors saves bandwidth? Or is it just more polite?

Re: CVE-2014-6271: Remote code execution through bash

#197

Post by fragmede »

Sanddancer wrote: post #193

Can someone with mod_security test a regex I wrote that should mitigate this? /\(. ?\)\s \{. ?\}\s \;/ from testing seems to catch any variants that I can think of that can trigger this bug, but I don't have a machine easily available to me at the moment to test with, unfortunately.

Redhat has some here: https://access.redhat.com/articles/1200223

Re: CVE-2014-6271: Remote code execution through bash

#198

Post by jimrandomh »

Sanddancer wrote: post #193

Can someone with mod_security test a regex I wrote that should mitigate this? /\(. ?\)\s \{. ?\}\s \;/ from testing seems to catch any variants that I can think of that can trigger this bug, but I don't have a machine easily available to me at the moment to test with, unfortunately.

Your regex was damaged by HN's comment formatting. To get it to post correctly, put it on a line with four leading spaces.

Re: CVE-2014-6271: Remote code execution through bash

#200

Post by Sanddancer »

Sanddancer wrote: post #193

Can someone with mod_security test a regex I wrote that should mitigate this? /\(. ?\)\s \{. ?\}\s \;/ from testing seems to catch any variants that I can think of that can trigger this bug, but I don't have a machine easily available to me at the moment to test with, unfortunately.

Repost, because HN "formatted" it for me

    /\((.*)?\)\s*\{(.*)?\}\s*\;/
I have qualms against redhat's fix, because it seems like it would create too many false positives, and additionally looks way too easy to work around just by adding spaces, etc.
Post reply on HN