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

281–290 of 432 posts

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

#281

Post by danielweber »

ars wrote: post #113
jvreeland wrote: post #99

Earlier quoted context omitted.

only in wheezy (security) right now. squeeze. jessie and wheezy are still vulnerable. https://security-tracker.debian.org/tracker/CVE-2014-6271

squeeze is not supported anymore but you can use squeeze-lts. It's been uploaded to squeeze-lts but has not reached the mirrors. You can get it manually from http://incoming.debian.org/debian-buildd/pool/main/b/bash/ if you can't wait.

I've got a Debian VM I maintain for giggles, and just out of masochism I've been running "apt-get update" and "apt-get upgrade" for a while and watching nothing change.. Am I doing something wrong or is the whole process just slow?

    deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
    deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

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

#282

Post by akavel »

nisa wrote: post #244
nandhp wrote: post #129

Earlier quoted context omitted.

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 wor…

IIUC, you're already pwned after the first line of your wrapper script, i.e. #!/bin/bash, as your CGI environment was already set before, and now you're running bash in it (unless FastCGI works differently, not by setting the environment as plain old CGI; I don't know FastCGI, but from a quick glance I think it works similarly)

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

#283

Post by ckuehl »

adamtj wrote: post #253
ckuehl wrote: post #137

Earlier quoted context omitted.

How are you testing it? If you're just pasting one of the proof-of-concept lines into zsh, such as this one: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" ...then you're really just executing bash. Replace "bash" in the line above with "zsh" and the "vulnerable" line is not printed.

No, it's not printed in your trivial example, but if you replace the simple "echo" command with any bash script, or any executable that calls a bash script, or any executable that invokes another program that calls a bash script, or ... then you're screwed. Even with the "zsh", this should print "vulnerable": env x='() { :;}; echo vulnerable' zsh -c "bash -c true" You don't have to use bash explicitly. It might be ca…

Right, the point being that bash is vulnerable, not zsh (as was suggested by the post I was replying to). I'm not claiming that using zsh as your interactive shell somehow makes you immune.

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

#285

Post by crylon »

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.

Linode can't modify packages; they're signed by the upstream distro. (Unless Linode added a key of their own to your apt keychain (apt-key list), but I've never seen that.)

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

#286

Post by mr_brown »

gwillem wrote: post #277

This is quite stealthy way to scan, as Accept headers are generally not logged: curl -H 'Accept: () { :;}; /usr/bin/curl -so /dev/null http://my.pingback.com' Found nothing so far though. IMHO the number of Bash CGI scripts in the wild must be pretty low.

import os os.putenv("ANYTHING", "() { :;}; echo bu") os.system("bash")

If this works (and it does) that means it's enough for a CGI script to invoke bash. It doesn't even have to be written in bash.

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

#287

Post by lefthand »

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.

My droplets in SFO have been updated. My droplets in nyc1 and nyc2 haven't.

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

#288

Post by antocv »

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…

Who the hell writes CGI scripts in 2014?

There is a reason PHP is to be kept away and not touched with a ten meter stick, it seems to spawn a shell for weird reasons, I dont think python or groovy apps do that. They're safe, unless you somewhere specifically invoke System.getRuntime().run("bash");

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

#289

Post by daveloyall »

daveloyall wrote: post #257
ars wrote: post #118

Earlier quoted context omitted.

It has not reached the lts mirrors yet, but you can get it from http://incoming.debian.org/debian-buildd/pool/main/b/bash/

As of 7:24 PM GMT the above link has the amd64 .deb for sid. Still waiting on the i386 .deb for sid. Your link and this link ( https://security-tracker.debian.org/tracker/CVE-2014-6271 ) useful when considered together.

The i386 .deb is available!

Aaaand now I'm done checking back on this thread. Have fun, folks! :)

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

#290

Post by detectify »

zobzu wrote: post #130
matchu wrote: post #83

Earlier quoted context omitted.

So, as a amateur sysadmin of a decently popular side project, what should I do? I've read over the post on the mailing list, and I think I understand the basic attack, but I'm having trouble understanding exactly how an attacker could run bash on my server and what I therefore need to patch (though I suspect that's intentional). Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server?

you should update all security updates, reliably, periodically, regardless of HN posts. you're probably not directly vulnerable for this very vuln, but then again, maybe you are. with enough vulns it gets complex enough to check that its easier to just update with all the security updates..

We just updated our scanner and included this CVE. You can run Detectify to see if your setup is vulnerable. We offer a recurring service that runs continuously and alerts you if you are exposed to new emerging vulnerabilities. This removes some of the complexity of always being on top of security alerts.
Post reply on HN