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

161–170 of 432 posts

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

#161

Post by teach »

pjungwir wrote: post #138
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.

It appears that Linode changes /etc/apt/sources.list to point to their own mirror of Ubuntu repositories, and as far as I can tell those are not updated yet. So I guess the solution is to wait or edit sources.list. Just FYI if you're on their systems!

Just did an update on my Linode and one of the updates was

    replace bash 4.1-2ubuntu3
So seems like it's there now.

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

#162

Post by mentat »

tptacek wrote: post #128
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…

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…

Very much so. I wasn't thinking through the library (and library equivalent) implications.

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

#163

Post by rmc »

larrys wrote: post #143
tptacek wrote: post #128

Earlier quoted context omitted.

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…

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?

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?

Usually no. This exploit should be vulnerable to any HTTP method. "unathenticed GETs" are the lowest security level of HTTP calls, so if they can be used as an attack vector, you should pay attention.

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

#164

Post by tinco »

chjj wrote: post #156
darklajid wrote: post #16

Earlier quoted context omitted.

Whoa. I tried this, ran pacaur -Suy and .. it's patched. Arch was fast.

$ x='() { :;}; echo vulnerable' bash -c 'echo test' vulnerable test $ pacman -Syu ... $ x='() { :;}; echo vulnerable' bash -c 'echo test' bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' test Benefits of using an OS with a real package manager.

Just don't turn it off after you've ran `pacman -Syu`, it will never boot again ;)

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

#166

Post by caust1c »

gegenschall wrote: post #37
darklajid wrote: post #16

Earlier quoted context omitted.

Whoa. I tried this, ran pacaur -Suy and .. it's patched. Arch was fast.

If you're on Arch, you might want to think about using dash as your /usr/bin/sh after updating, see [0]. [0] https://wiki.archlinux.org/index.php/Dash

Also make sure your mirror is up to date. When I updated this morning, osuosl was out of date (and still is as of this comment: https://www.archlinux.org/mirrors/osuosl.org/125/)

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

#167

Post by diltonm »

justincormack wrote: post #21
kalops wrote: post #3

so basically turn off AcceptEnv in sshd_config?

Also don't use bash for running any scripts. You never should anyway, in a sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash which is not vulnerable. Unfortunately the Redhat derived distros do use bash as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash is for users not scripts.

Dash sucks, bash rocks. Dash isn't even close to being as capable of a shell as Bash.

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

#168

Post by MrUnderhill »

adamt wrote: post #124
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.

I was wondering about this too. My thinking was, if a user's laptop is compromised (and has the exploit in LC_TIME, TERM or similar), and the user then SSH in to a server with exploitable bash, the nefarious command will presumably be executed without the user knowing. But of course, if the laptop is compromised that badly, it could probably wreak havoc to the server anyway.

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

#169

Post by peterwwillis »

Know what isn't vulnerable to this? Perl CGI scripts with taint mode enabled. http://perldoc.perl.org/perlsec.html#Taint-mode

  You may not use data derived from outside your program to affect something
  else outside your program--at least, not by accident. All command line
  arguments, environment variables, locale information (see perllocale),
  results of certain system calls (readdir(), readlink(), the variable
  of shmread(), the messages returned by msgrcv(), the password,
  gcos and shell fields returned by the getpwxxx() calls), and all
  file input are marked as "tainted".

  Tainted data may not be used directly or indirectly in any command
  that invokes a sub-shell, nor in any command that modifies files,
  directories, or processes, with the following exceptions:
Post reply on HN