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

111–120 of 432 posts

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

#111

Post by larrys »

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 this is. [1]

Perhaps you could clarify with some examples of why (see child comment "So, as a amateur sysadmin of a decently popular side project") you think this applies to anyone who is "responsible for the security of any system"?

[1] Me for one because I'm not seeing the "Drop everything" priority for any of the systems that I have control over given the way they are configured. That said I'd like to hear more of course.

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

#112

Post by clarry »

agwa wrote: post #106
asveikau wrote: post #86

Earlier quoted context omitted.

I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it. If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your…

The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. As long as you're not passing arguments from outside sources to the command, using system() should be OK.

And in some cases invoking the shell and letting it do its thing is expected, intended and desirable.

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

#113

Post by ars »

jvreeland wrote: post #99
dllthomas wrote: post #45

Earlier quoted context omitted.

It's fixed in Debian as well.

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.

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

#115

Post by yebyen »

dllthomas wrote: post #103
yebyen wrote: post #90

Earlier quoted context omitted.

I am not so sure. Debian sid (i386) with current updates, the example test shows I am still vulnerable. 4.3-9 bash

I ran env x='() { :;}; echo vulnerable' bash -c "echo this is a test" and got vulnerable this is a test so I did apt-get update apt-get install bash and now I get bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test bash version 4.2.37(1)-release Edited: Seems like jvreeland has a clearer picture: https://news.ycombinator.com/item?id=8362309

Yeah, I was current yesterday and I'm current today, with both apt-get update and upgrades. Your version number is lower than mine, you must be on either stable or testing.

ii bash 4.3-9 i386 GNU Bourne Again SHell

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

vulnerable this is a test

From the FAQ:

> Does sid have security updates?

Not in the same sense that stable does. If the maintainer of a package fixes a security bug and uploads the package, it'll go into sid by the normal means. If the maintainer doesn't do that, then it won't. The security team only covers stable (and possibly testing... there's a pending issue for that case).

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

#116

Post by sauere »

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?

> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server?

Yes. Patch is out.

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

#117

Post by nitrogen »

nknighthb wrote: post #31
justincormack wrote: post #24

Earlier quoted context omitted.

People still shell out to do stuff from scripts from all sorts of languages. Unless these sanitize the environment they would be vulnerable.

Unless you're using CGI, your system environment will not be contaminated. CGI is vulnerable because it relies on passing untrusted data in environment variables. No other gateway interface I'm familiar with does.

Are you certain that no method of invoking a dynamic script sets environment variables to values controlled by requests? If so, it sounds like even an innocent call to system("lame a.wav b.mp3") could lead to code execution.

Edit: also, you may be surprised to find that some "libraries" are actually wrappers around external binaries (e.g. libgpgme). If any of them used a system() or exec() call that preserves environment, and the binary or the library ever invokes bash (e.g. via system()), then trouble will ensue.

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

#118

Post by ars »

agwa wrote: post #100
kazinator wrote: post #58

Earlier quoted context omitted.

I have a Debian Squeeze system. Just ran apt-get upgrade and bash wasn't upgraded at all. Just other things like CUPS, exim4, pgsql, ...

Squeeze doesn't have regular security support anymore. A subset of packages on i386 and amd64 are receiving long term security support, but you need to enable the Squeeze LTS repo: https://wiki.debian.org/LTS/Using

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

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

#119

Post by Crito »

flexd wrote: post #82
flebron wrote: post #63

Maybe I'm doing something wrong, but I just tested it in ZSH (5.0.5, Linux) and the same vulnerable behavior seems to show up.

I see this in zsh 5.0.0 on Ubuntu, and on OSX as well! zsh 5.0.2 (x86_64-apple-darwin13.0)

I'm not seeing this on zsh 4.3.17. Exactly what did you run to see this?

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

#120

Post by JoshTriplett »

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 privileged environments typically filter out attempts to set PATH, LD_LIBRARY_PATH, and so on.)

This applies even if your shell script or shell snippet uses the full paths to commands. For instance:

    $ env '/sbin/foo'='() { echo exploit; }' bash -c '/sbin/foo'
    exploit
Post reply on HN