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

241–250 of 432 posts

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

#241

Post by stouset »

larrys wrote: post #143
tptacek wrote: post #128

Earlier quoted context omitted.

Any library anywhere in any application you run that calls out to bash that is called by any other library in that application, so long as that application is somehow hooked up to a web server, is potentially an unauthenticated GET request away from code execution; the exploit for this is potentially so simple that attackers can craft a single request, spider the Internet, and collect shells from applications you run…

So for example if you don't run web servers that are front facing on the internet (and you trust your (for example) intranet) then does this become an "asap" rather than a "drop everything"? "is potentially an unauthenticated GET request" Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?

No, that is not what tptacek is saying.

Unauthenticated GET requests were just an example of something that can invoke this behavior. If you have any network-enabled service that's capable of spawning a shell, you can have attack vectors open.

Possible vectors include things like DHCP clients, SSH, web servers, etc. Lots of things open shells for reasons you wouldn't intuitively expect. It's very likely that there are many creative vectors for exploitation that will be discovered in the coming hours.

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

#242

Post by notacoward »

JoshTriplett wrote: post #218
notacoward wrote: post #174

Earlier quoted context omitted.

It's not just you. The fact that an environment variable can override e.g. "git" to do something else is a real problem requiring separate protection. However, that's effectively PATH injection rather than code injection so it's already addressed in many cases.

Except that most environments already filter out attempts to control PATH, LD_LIBRARY_PATH, and similar; they don't filter out "git".

I agree. In the next few months, we'll probably be finding out about some of the cases where neither existing sanitization nor the half-fix for this problem was sufficient to prevent exploits in this family. :(

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

#243

Post by pritambaral »

prothid wrote: post #220
ars wrote: post #32

Earlier quoted context omitted.

Lots? Really? PHP was one of the first to have a dedicated apache module. Perl is much more likely to be CGI.

Yes, lots. nginx + php is very popular.

Is fastCGI the same thing as CGI, for this case, though?

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

#244

Post by nisa »

nandhp wrote: post #129
larrys wrote: post #111

Earlier quoted context omitted.

"If you are responsible for the security of any system, this is your immediate, drop-everything priority." Why don't you explain in plain english exactly why you feel this is the case? "Drop-everything" in other words (or even close to that). Give some scenarios. After all anyone who knows a great deal doesn't need that advice the people who need that advice are ones that don't know enough to know what the impact of…

Because this allows execution of arbitrary commands from any unsantized environment variable. Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string. GET / HTTP/1.0 User-Agent: () { :; }; rm -rf / Restricted SSH accounts (like the ones used by GitHu…

Is this also dangerous to common FastCGI-Wrappers? E.g. this is used by Virtualmin:

    #!/bin/bash
    PHPRC=$PWD/../etc/php5
    export PHPRC
    umask 022
    export PHP_FCGI_CHILDREN
    PHP_FCGI_MAX_REQUESTS=99999
    export PHP_FCGI_MAX_REQUESTS
    SCRIPT_FILENAME=$PATH_TRANSLATED
    export SCRIPT_FILENAME
    exec /usr/bin/php5-cgi
At least SCRIPT_FILENAME is user input isn't it? I'm really not sure but like to have some clarity. It should not work because it's likely impossible to have () at the beginning of the SCRIPT_FILENAME? but can someone give some hints? It's common to have bash/sh wrapper script: https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#exampl...

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

#245

Post by svankmajer »

drzaiusapelord wrote: post #237
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.

If you just want to update that package then: apt-get update apt-get install --only-upgrade bash fwiw, Linode's mirrors are up with the latest version yet Digital Ocean's are not. I lose faith in DO everytime I remote into my VM. They just seen like an amateurish shop.

I successfully upgraded bash on my droplets a couple minutes ago.

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

#246

Post by dfc »

Danieru wrote: post #145
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.

You should also reboot to ensure no running instances of bash are vulnerable.

  $ apt-cache show debian-goodies 
    
    checkrestart    - Help to find and restart processes which are using old
                      versions of upgraded files (such as libraries)

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

#247

Post by cookiecaper »

ay wrote: post #233
cookiecaper wrote: post #121

Earlier quoted context omitted.

If you're still waiting for mirrors and such to sync, you can install these packages manually on the LTS releases with the snippet here: http://hastebin.com/oraheyipug.hs

Looks like the patched version and the pre-patched version show the same version, or am I being stupid and missing something ? ayourtch@mcmini:~/bash-patch$ ls bash_4.2-2ubuntu2.2_amd64.deb bash-builtins_4.2-2ubuntu2.2_amd64.deb t ayourtch@mcmini:~/bash-patch$ dpkg -x bash_4.2-2ubuntu2.2_amd64.deb t ayourtch@mcmini:~/bash-patch$ diff -c t/bin/bash /bin/bash Binary files t/bin/bash and /bin/bash differ ayourtch@mcmini…

Only the build/patchset version is incremented in these packages (the -2ubuntu2.2). You can see the package version with dpkg -s bash | grep Version.

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

#248

Post by sp332 »

steveklabnik wrote: post #188
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.

https://launchpad.net/ubuntu/+source/bash/4.3-7ubuntu1.1 seems to be at least one version of the fix, I'm unsure about LTS and other releases.

http://www.ubuntu.com/usn/usn-2362-1/

Ubuntu 14.04 LTS: bash 4.3-7ubuntu1.1

Ubuntu 12.04 LTS: bash 4.2-2ubuntu2.2

Ubuntu 10.04 LTS: bash 4.1-2ubuntu3.1

For releases in-between, you should be able to manually download one of those versions from http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ and install it. I wonder how many vulnerable boxes there are that won't get these updates because Ubuntu stops support after 9 months. There must be tons of boxes running 13.10, it's not even a year old yet.

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

#249

Post by Eclyps »

prothid wrote: post #221
Eclyps wrote: post #204

Amazon's Linux distro for EC2 is still waiting for a patch. EDIT: Finally got things updated. Bulletin can be found here: https://alas.aws.amazon.com/ALAS-2014-418.html If yum isn't finding the update, try running "yum clean all" and then "yum update bash"

I'm considering pulling an rpm from elsewhere until they have this in place.

It's updated now

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

#250

Post by iancarroll »

aaronem wrote: post #230
teach wrote: post #196

Earlier quoted context omitted.

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?

It probably ensures that you get the Linode-customized flavors of packages where such exist, so that, for example, you don't inadvertently upgrade your kernel to a build without the ability to mount Linode disks.

It's also meant to help you and Linlde save bandwidth!
Post reply on HN