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

341–350 of 432 posts

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

#341

Post by jMyles »

CSDude wrote: post #338
daveloyall wrote: post #327

There's some misunderstanding of how the one-liner works, so here's a writeup. You can break the one-liner into two lines to see what is happening. 1. hobbes@media:~$ export badvar='() { :;}; echo vulnerable' 2. hobbes@media:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'" 3. bash: warning: badvar: ignoring function definition attempt 4. bash: error importing function definition for `badvar' 5. I am…

I finally understand how it can be used.

I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an environment variable?

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

#342

Post by smsm42 »

antocv wrote: post #288
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…

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");

PHP never "spawns shell for weird reasons" - it would spawn shell if you ask it to spawn shell. Just as any other language would, if you ask it. Still, many apps may use shell indirectly - e.g. to execute some system function, to call out to some tool, etc. - and those may be vulnerable even if original code was not CGI script. Moreover, you don't have to run specifically bash - any command execution may go through shell, which may be bash, e.g. Runtime.getRuntime().exec() in Java. Thus it may be not very easy to pinpoint all the places where this bug could sneak in.

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

#343

Post by smsm42 »

jMyles wrote: post #341
CSDude wrote: post #338

Earlier quoted context omitted.

I finally understand how it can be used.

I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an environment variable?

In a webserver, like Apache, environment variables are set from headers sent by the client, e.g. each header like Cookie would produce variable like HTTP_COOKIE. These variables can contain any data that the user sent. If Apache uses external code (like PHP, Ruby, Python, etc.) to process the request, it may pass these variables to that code, and if that code runs some command on the system, these variables may be passed to the command shell, which would lead to code contained in the variable to be executed at that point.

This can also happen with other service processes - such as OpenSSH, that sets ORIG_SSH_COMMAND variable to the command that the user supplies. That may allow people to break out of restricted accounts -i.e. accounts that are supposed to run just one command (ssh-based services, like SVN or Git, may be an example) and run arbitrary commands under such user.

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

#344

Post by thejosh »

scintill76 wrote: post #238
_wmd wrote: post #56

As an example of who might be impacted, since openssh preserves the original command line passed to the ssh server when authenticating a public key that has a fixed command associated in authorized_keys, GitHub and BitBucket security teams are probably both having a really exciting day.

This vulnerability is the kind of reason I would have a stripped-down OpenSSH for public users, if I were them. Hard-code to do what they need, don't use configuration files, remove any features not needed. For example, to print the "You've successfully authenticated, but GitHub does not provide shell access." a user gets trying to ssh to github.com, don't invoke anything, print it directly from the SSH server.

This is what Atlassian Stash does.

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

#345

Post by [deleted] »

stouset wrote: post #241
larrys wrote: post #143

Earlier quoted context omitted.

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

[deleted]

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

#346

Post by vertex-four »

jMyles wrote: post #341
CSDude wrote: post #338

Earlier quoted context omitted.

I finally understand how it can be used.

I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an environment variable?

CGI scripts is the most obvious way - when executing a CGI script, each HTTP header gets translated into an environment variable - but I have no doubt there's all sorts of odd network-facing apps which set environment various and then run a command, even if you're not running CGI scripts.

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

#348

Post by base698 »

jMyles wrote: post #341
CSDude wrote: post #338

Earlier quoted context omitted.

I finally understand how it can be used.

I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an environment variable?

There are a lot of scripts the do something like: curl 'http://myradframework.com/script.sh' | bash

That'd be pretty easy to do this if they weren't honest or man in the middle attack the site.

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

#349

Post by 0x0 »

jMyles wrote: post #341
CSDude wrote: post #338

Earlier quoted context omitted.

I finally understand how it can be used.

I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an environment variable?

Lots of internet facing software fills env vars with user data: Apache may set several SSL_* vars and HTTP_* vars, ssh may set LC_*, LANG, TERM, etc; procmail and other smtp filters probably have their fair share too.

The moment any child process of these hit a system() or popen() like call, /bin/sh initializes and may hit the bug.

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

#350

Post by Erwin »

0x0 wrote: post #334

The currently published fix is claimed to be incomplete: https://twitter.com/taviso/status/514887394294652929

That works for me too. I was first unsure but breaking it up into an export Z=.... and then running bash -c 'echo date' on a separate line seems to execute essentially date > echo.

Can anyone explain what's going on there? Seems like defining a function within a nameless function; how does it end up with this redirect? I'm not sure what the exploitabiliy of this is; is it just essentially $1 > $0 ?

Post reply on HN