Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

301–310 of 432 posts

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

#301

Earlier quoted context omitted.

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.

Much easier to implement a custom captive shell (default login shell for user) then to mess with the crypto system.

Maybe. Actually, it looks like Github is using libssh, which is along the lines of what I was thinking, without having to mess with crypto too much, as you say.

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

#302
post #204

Amazon's Linux distro for EC2 is still waiting for a patch. EDIT: Finally got things updated. Bulletin can be found here: https://alas.aws.amazon.com/ALAS-2014-418.html If yum isn't finding the update, try running "yum clean all" and then "yum update bash"

If yum still doesn't find it, you may be on an older release. Try "yum --releasever=2014.09 update bash"

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

#305
post #298

Funny, this works even after bash fix / upgrade env X='() { (a)=>\' sh -c "echo date"; cat e From http://seclists.org/oss-sec/2014/q3/672

I replaced "sh" with "bash" in the above, and on my patched system it creates a file called "echo" with the date in it. Can anyone explain how this works? Is it an exploit?

Edit: From my experiments, the name in (a) doesn't matter, and "echo" and "date" can be changed. The thing in echo's position is where the output goes (and can be an absolute path!), and "date" is a command that is run. Still no idea how it works, as I'm not very familiar with shell syntax and Googling symbols like "=>" is mostly useless. It may even be meaningless and is just garbage to get bash into a state that causes this to happen?

Edit 2: http://seclists.org/oss-sec/2014/q3/679 has a small example. "Tavis and I spent a fair amount of time trying to figure out if this poses a more immediate risk, but so far, no dice. It strongly suggests that the parser is fragile and that there may be unexpected side effects, though"

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

#306
post #204

Amazon's Linux distro for EC2 is still waiting for a patch. EDIT: Finally got things updated. Bulletin can be found here: https://alas.aws.amazon.com/ALAS-2014-418.html If yum isn't finding the update, try running "yum clean all" and then "yum update bash"

Still waiting for a fix on Beanstalk. Neither "yum clean all" followed by "yum update bash" nor "yum --releasever=2014.09 update bash" currently work.

EDIT: relevant AWS threads

https://forums.aws.amazon.com/thread.jspa?threadID=161489

https://forums.aws.amazon.com/thread.jspa?threadID=161529&ts...

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

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

I am on linode and precise LTS. I did this, and I got no bash update. What am I doing wrong?

edit: and how do I know if I am still vulnerable?

edit2: ok, this is the test

  env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
and apparently I am already patched. So that's good.

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

#309
post #248

Earlier quoted context omitted.

https://launchpad.net/ubuntu/+source/bash/4.3-7ubuntu1.1 seems to be at least one version of the fix, I'm unsure about LTS and other releases.

http://www.ubuntu.com/usn/usn-2362-1/ Ubuntu 14.04 LTS: bash 4.3-7ubuntu1.1 Ubuntu 12.04 LTS: bash 4.2-2ubuntu2.2 Ubuntu 10.04 LTS: bash 4.1-2ubuntu3.1 For releases in-between, you should be able to manually download one of those versions from http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ and install it. I wonder how many vulnerable boxes there are that won't get these updates because Ubuntu stops support after…

It's for that reason that I just ignore anything that's not an LTS release. It's never worth the hassle for me.

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

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

DigitalOcean uses mirrors too, so you have to change your /etc/apt/sources.list file or wait.
Post reply on HN