Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

231–240 of 432 posts

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

#233
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?

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

Looks like the patched version and the pre-patched version show the same version, or am I being stupid and missing something ?

  ayourtch@mcmini:~/bash-patch$ ls
  bash_4.2-2ubuntu2.2_amd64.deb bash-builtins_4.2-2ubuntu2.2_amd64.deb  t
  ayourtch@mcmini:~/bash-patch$ dpkg -x bash_4.2-2ubuntu2.2_amd64.deb t
  ayourtch@mcmini:~/bash-patch$ diff -c t/bin/bash /bin/bash
  Binary files t/bin/bash and /bin/bash differ
  ayourtch@mcmini:~/bash-patch$ t/bin/bash --version
  GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
  Copyright (C) 2011 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 

  This is free software; you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  ayourtch@mcmini:~/bash-patch$ /bin/bash --version
  GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
  Copyright (C) 2011 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  
  This is free software; you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  ayourtch@mcmini:~/bash-patch$ sha1sum t/bin/bash
  9eeed02173db163b013933eff3b8c6aa3697f67f  t/bin/bash
  ayourtch@mcmini:~/bash-patch$ sha1sum /bin/bash
  3384fadf84146a4d4b6b7f529f615e9947b4ac99  /bin/bash
  ayourtch@mcmini:~/bash-patch$

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

#236

Interestingly enough ancient BASH version 3.2 on Mac OS X 10.9.5 is not vulnerable: $ echo $BASH_VERSION 3.2.51(1)-release $ x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test $ I manually patched my BASH 4.3 to patch level 25 so it's not vulnerable either. $ echo $BASH_VERSION 4.3.25(1)-re…

Since other people are reporting that their copies of bash 3.2.51 are vulnerable, I suspect that the version of bash that is currently running in that terminal is 3.2.51 and vulnerable, but the version of bash that you are invoking from that vulnerable version of bash is not.

In other words, I suspect that:

    $ echo $BASH_VERSION
and

    $ bash --version
Will report different version numbers.

If you start a new terminal and try `echo $BASH_VERSION`, you will probably see a different version as well.

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

#237
post #116
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?

> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server? Yes. Patch is out.

If you just want to update that package then:

apt-get update

apt-get install --only-upgrade bash

fwiw, Linode's mirrors are up with the latest version yet Digital Ocean's are not. I lose faith in DO everytime I remote into my VM. They just seen like an amateurish shop.

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

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

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

#239
post #236

Interestingly enough ancient BASH version 3.2 on Mac OS X 10.9.5 is not vulnerable: $ echo $BASH_VERSION 3.2.51(1)-release $ x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test $ I manually patched my BASH 4.3 to patch level 25 so it's not vulnerable either. $ echo $BASH_VERSION 4.3.25(1)-re…

Since other people are reporting that their copies of bash 3.2.51 are vulnerable, I suspect that the version of bash that is currently running in that terminal is 3.2.51 and vulnerable, but the version of bash that you are invoking from that vulnerable version of bash is not. In other words, I suspect that: $ echo $BASH_VERSION and $ bash --version Will report different version numbers. If you start a new terminal an…

Excellent insight!

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

#240
post #236

Interestingly enough ancient BASH version 3.2 on Mac OS X 10.9.5 is not vulnerable: $ echo $BASH_VERSION 3.2.51(1)-release $ x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test $ I manually patched my BASH 4.3 to patch level 25 so it's not vulnerable either. $ echo $BASH_VERSION 4.3.25(1)-re…

Since other people are reporting that their copies of bash 3.2.51 are vulnerable, I suspect that the version of bash that is currently running in that terminal is 3.2.51 and vulnerable, but the version of bash that you are invoking from that vulnerable version of bash is not. In other words, I suspect that: $ echo $BASH_VERSION and $ bash --version Will report different version numbers. If you start a new terminal an…

Yes - the shell currently running is probably the user's login shell, and the shell in e.g. /usr/local/bin/bash was probably installed by Homebrew or MacPorts.
Post reply on HN