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

371–380 of 432 posts

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

#371

Post by Negitivefrags »

andrew13 wrote: post #361

It might still be an issue. The patches may not have done enough. $ env X='() { (a)=>\' sh -c "echo date"; cat echo https://twitter.com/taviso/status/514887394294652929# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

Can anyone confirm that this is still a security issue?

My reading of this is that it's weird, and it's certainly a bug in the parser, but because you don't get to put the executable code in the environment variable it's not an RCE exploit like the last bug was.

Does anyone have confirmation that this new bug allows you to RCE with control of the value of an environment variable alone?

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

#372

Post by AgentME »

pbhjpbhj wrote: post #357
vertex-four wrote: post #346

Earlier quoted context omitted.

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.

Surely though the CGI framework sanitises the headers first? Otherwise this seems like it's a pretty predictable problem - isn't "always sanitise user data" the cardinal rule of backends. I can certainly imagine that I might have designed a web page that passed user input direct to a BASH script to do a ping or some such, but not if it's public facing.

What sanitization do you expect the CGI framework to apply to the header value representing the user agent? str_replace($userAgent, '() {', 'no bash bug for you')?

Only a few environment variables are given any meaning by the system. Other environment variables don't have any predefined meaning and can be any null-terminated string.

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

#373

Post by thaumaturgy »

Negitivefrags wrote: post #371
andrew13 wrote: post #361

It might still be an issue. The patches may not have done enough. $ env X='() { (a)=>\' sh -c "echo date"; cat echo https://twitter.com/taviso/status/514887394294652929# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

Can anyone confirm that this is still a security issue? My reading of this is that it's weird, and it's certainly a bug in the parser, but because you don't get to put the executable code in the environment variable it's not an RCE exploit like the last bug was. Does anyone have confirmation that this new bug allows you to RCE with control of the value of an environment variable alone?

That was my initial reaction too, but I'm not so sure now that the bash maintainer has responded. I'm trying to get a better PoC working.

edit: OK, I give. I don't understand how this is different from,

    env z='' echo oops
So, assuming you have Stupid Server 2.0, and SS 2.0 allows you to send an Accept: header with,

    '' evil command here
...you still need to find a way to execute that command, which is different from CVE-2014-6271, which caused function embedded in environment variables to be executed when they were read.

Am I missing something?

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

#374

Post by timv »

Negitivefrags wrote: post #371
andrew13 wrote: post #361

It might still be an issue. The patches may not have done enough. $ env X='() { (a)=>\' sh -c "echo date"; cat echo https://twitter.com/taviso/status/514887394294652929# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

Can anyone confirm that this is still a security issue? My reading of this is that it's weird, and it's certainly a bug in the parser, but because you don't get to put the executable code in the environment variable it's not an RCE exploit like the last bug was. Does anyone have confirmation that this new bug allows you to RCE with control of the value of an environment variable alone?

As best I can tell no one has (publicly) demonstrated a mechanism to turn this into an RCE (despite efforts to do so).

http://seclists.org/oss-sec/2014/q3/679

Of course, that doesn't mean there isn't one. It's clearly a reasonably significant issue - the setting of environment variables can cause unintended file system writes (and the same parsing bug can be used for reads) - and you're better off assuming that someone will determine an exploit based on it.

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

#375

Post by timv »

andrew13 wrote: post #361

It might still be an issue. The patches may not have done enough. $ env X='() { (a)=>\' sh -c "echo date"; cat echo https://twitter.com/taviso/status/514887394294652929# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

The same trick can be used to read files as well

  $ date -u > file1
  $ env -i X='() { (a)=
Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.

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

#376

Post by scintill76 »

Erwin wrote: post #350
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 ?

The redirect at the end of the env var seems to be "remembered" even though the syntax error aborts the function definition, then the first arg is taken as the path to redirect to, and the following args as the command to execute. (I haven't dug into the actual parser, this is just my intuitive understanding.) It does seem to be about like $1 > $0, so not generally exploitable.

Here's an example using it to read files instead of write: https://news.ycombinator.com/item?id=8365205 But still, not as universal of an exploit as the original.

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

#377

Post by timv »

thaumaturgy wrote: post #373
Negitivefrags wrote: post #371

Earlier quoted context omitted.

Can anyone confirm that this is still a security issue? My reading of this is that it's weird, and it's certainly a bug in the parser, but because you don't get to put the executable code in the environment variable it's not an RCE exploit like the last bug was. Does anyone have confirmation that this new bug allows you to RCE with control of the value of an environment variable alone?

That was my initial reaction too, but I'm not so sure now that the bash maintainer has responded. I'm trying to get a better PoC working. edit: OK, I give. I don't understand how this is different from, env z='' echo oops So, assuming you have Stupid Server 2.0, and SS 2.0 allows you to send an Accept: header with, '' evil command here ...you still need to find a way to execute that command, which is different from C…

Am I missing something?

I think so, but the sample exploit isn't really designed to give a clear understanding if you don't already know what's going on.

Try this:

  $ export X="() { (a)=>\\"
  $ bash -c 'echo date'
  bash: X: line 1: syntax error near unexpected token `='
  bash: X: line 1: `'
  bash: error importing function definition for `X'
  $ cat echo
  Thu Sep 25 02:27:07 UTC 2014
Setting "X" in that way confuses the bash env variable parser. It barfs at the "=" and leaves the ">\" unparsed

AFAICT (without digging deep into the code) that leave in the execution buffer as ">\[NEWLINE]echo date" which gets treated the same as

  date > echo

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

#379

Post by thaumaturgy »

timv wrote: post #377
thaumaturgy wrote: post #373

Earlier quoted context omitted.

That was my initial reaction too, but I'm not so sure now that the bash maintainer has responded. I'm trying to get a better PoC working. edit: OK, I give. I don't understand how this is different from, env z='' echo oops So, assuming you have Stupid Server 2.0, and SS 2.0 allows you to send an Accept: header with, '' evil command here ...you still need to find a way to execute that command, which is different from C…

Am I missing something? I think so, but the sample exploit isn't really designed to give a clear understanding if you don't already know what's going on. Try this: $ export X="() { (a)=>\\" $ bash -c 'echo date' bash: X: line 1: syntax error near unexpected token `=' bash: X: line 1: `' bash: error importing function definition for `X' $ cat echo Thu Sep 25 02:27:07 UTC 2014 Setting "X" in that way confuses the bash…

Oh that's neat.

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

#380

Post by JackC »

pbhjpbhj wrote: post #368
smsm42 wrote: post #343

Earlier quoted context omitted.

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

> OpenSSH, that sets ORIG_SSH_COMMAND variable to the command that the user supplies // So they set shell vars without sanitising them first?

As an analogy, suppose I go to a website written in PHP and register with the username "Robert'); DROP TABLE Students;--". A correct PHP script will sanitize the name; it'll escape the quote and run something like `update users set name='Robert\'); DROP TABLE Students;--'`. If mysql then ignores the backslash and drops the Students table, that is definitely a mysql problem and not a PHP problem. Doing any more on the PHP side to "sanitize" the name would actually break the script by screwing up valid names.

In this case, the shell variables are correctly sanitized by Apache or whatever, and then mishandled by bash. For example, imagine this very simple system:

- Web server receives a GET request with the user's name. - Web server sets the environment variable USERS_NAME=''. - Web server sends back the result of running `bash print_welcome_message.sh`.

It might not be considered great design, but there's nothing inherently insecure in this system, and there are plenty of actual systems that more or less work this way. And it's also perfectly valid for a user to have the name `() { :;}; echo vulnerable`. It ought to work fine to set USERS_NAME to that value and send back `Welcome, () { :;}; echo vulnerable.`

Instead, an unpatched bash will execute the contents of USERS_NAME. The only way for the web server to prevent that would be to change the user's name, which would be wrong behavior -- given a properly working shell, it would print the wrong name in the response. The web server does its sanitization job correctly when it successfully sets USERS_NAME in spite of any single quotes or what-have-you -- this part isn't its problem.

Post reply on HN