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

121–130 of 432 posts

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

#121

Post by cookiecaper »

matchu wrote: post #83
jimrandomh wrote: post #26

If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.

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?

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

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

#122

Post by fluidcruft »

_b8r0 wrote: post #60

My OSX Mavericks install appears to be affected: foom:~ steve$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test

Doesn't OSX ship the 8-year-old bash 3.2 (2006) i.e. the last version available as GPLv2? (Apple hates GPLv3)

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

#124

Post by adamt »

ck2 wrote: post #27

http://www.csoonline.com/article/2687265/application-securit... Another attack surface is OpenSSH through the use of AcceptEnv variables. As well through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.

On most systems I've found this works: LC_TIME='() { :;}; echo vulnerable' ssh

Not sure of the impact of this, as the user would need to have a remote permissions anyway for the SSH login to occur. But if there was some form of restricted shell that then spawned bash it might potentially create an attack vector.

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

#125

Post by jimrandomh »

JoshTriplett wrote: post #120

Is it just me, or are the patches "fixing" the vulnerability woefully insufficient? With the patch, bash stops executing the trailing code, but it still allows defining arbitrary shell functions from environment variables. So, even though the patch fixes the ability to exploit this via SSH_ORIGINAL_COMMAND or HTTP_*, anything that can set environment variables can still override an arbitrary command. (Note that privi…

Attacker-controlled environment variable names are a rare scenario, and one that probably has you hosed no matter what. Attacker-controlled environment variable values, on the other hand, are not so rare, and if not for this vulnerability they wouldn't be a problem.

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

#126

Post by karlkatzke »

ilconsigliere wrote: post #85
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?

It will be once they release a patch, yes https://security-tracker.debian.org/tracker/CVE-2014-6271

Already out on Ubuntu, I believe?

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

#127

Post by apawloski »

jrochkind1 wrote: post #51
ilconsigliere wrote: post #40

Am I wrong in thinking that seems a bit worse than Heartbleed?

The exploit is worse. But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing. Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge. But as it is... I'm not sure?

Google inurl:cgi-bin inurl:.sh

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

#128

Post by tptacek »

larrys wrote: post #111
jimrandomh wrote: post #26

If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.

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

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 that you forgot you even ran, at which point they'll own your whole data center.

Helpful?

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

#129

Post by nandhp »

larrys wrote: post #111
jimrandomh wrote: post #26

If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.

"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 GitHub) have a setting to restrict the user to a specific command (e.g. /usr/local/bin/run-git-only --github-user=octocat). The original command is passed in an environment variable SSH_ORIGINAL_COMMAND. If bash is used anywhere along the way (say, if /usr/local/bin/run-git-only --github-user=octocat is a shell script), then this is a problem:

    ssh git@example.com '() { :; }; rm -rf /'
There are surely lots of other ways to get servers to run bash shells with arbitrary environment variables. That's why this is bad.

Edit: as others have pointed out, even non-bash CGI scripts that use a shell to run external processes are vulnerable For example, system("/usr/local/bin/whatever --some-fixed-option") would normally be considered safe since there's no untrusted data in the command-line (although perhaps it would be considered poor design), but it'll run a shell to do the whitespace splitting. If that shell is bash....

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

#130

Post by zobzu »

matchu wrote: post #83
jimrandomh wrote: post #26

If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.

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..

Post reply on HN