Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

411–420 of 432 posts

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

#411

Earlier quoted context omitted.

This won't work; you need sudo make install Given the circumstances, a lot of people without much software experience will be reading this message and simply copying and pasting; it's worth getting it right. On Ubuntu, you'll probably want to ./configure --prefix=/usr/bin . If you install in /usr/local/bin (the default), bash will effectively no longer be updated by apt-get.

That should probably have been ./configure --prefix=/usr --bindir=/bin --sbindir=/sbin --sysconfdir=/etc Once upon a time, distributions documented their build configurations. Or maybe it's that I used to only use FreeBSD.

That script assumes that it is executed as root. There's indeed a possible problem with /usr/local/bin/bash vs. /bin/bash with Ubuntu update from 8.04 to 10.04 (since Ubuntu 8.04 itself is no longer updateable), thus I asked that question in the end of my post. To mitigate it, one can just add:

  mv /usr/local/bin/bash /bin
as the last line.

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

#412
post #299

Here's how to patch Ubuntu 8.04 or anything where you have to build bash from source: #assume that your sources are in /src cd /src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 0 25);do patch -p0 Not sure if Ubun…

This sequence failed for me because my Ubuntu 8.04 didn't have patch installed.

I found a source copy at https://launchpad.net/ubuntu/+source/patch/2.5.9-4 and built/installed that first. The resulting fix appears to work (after copying resulting bash to /bin as noted elsewhere).

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

#413
post #299

Here's how to patch Ubuntu 8.04 or anything where you have to build bash from source: #assume that your sources are in /src cd /src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 0 25);do patch -p0 Not sure if Ubun…

Does this fix CVE-2014-7169 as well, or just CVE-2014-6271?

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

#415
post #360

Earlier quoted context omitted.

So it's a sort of injection attack that targets inputs to bash that manage to bypass normal sanitisation? Apache takes SSL_* headers, say, from a client and simply passes those to BASH and this exploit means that BASH will execute a payload dropped in to the header?Am I close? Wouldn't that also be an Apache [httpd] bug in that it's allowing unsanitised user data to hit the shell? Similarly are you saying that if I s…

It's kind of the equivalent of a web app that basically evals any given GET parameter with a specially crafted value. Apache sets environment variables, it does not pass user input directly to bash as code or anything like that. The fact that bash can be tricked to execute this code is a problem that needs to be addressed by bash, not any other software.

>"Apache sets environment variables, it does not pass user input directly to bash as code or anything like that." //

This is contrary to how I'm understanding the situation. BASH, or whichever shell is being used, sets environment variables; Apache httpd et al. pass off some user data (from clients, eg browser headers) to the shell to set variables under limited circumstances [like use of CGI], no? Then when BASH gets initialised something is happening in the parsing of variables causing statements included with the variable (which variable can be a function definition) to be executed.

I realise now that as things stand you can't sanitise many of the fields [like http client headers] as they don't have well defined forms. But setting variables for use by BASH seems as close to "pass user input directly to bash" as you're going to get.

Mainly I'm doubting that all these different apps duplicate code to set env variables when the shell already knows how to do it, doesn't seem very *nixy. Happy to be corrected as I'm - as I'm sure you've guessed - a bit out of my depth.

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

#416
post #170

Is someone from Heroku online here right now? My apps are all affected and since I am trusting Heroku with this, I am hoping they patch the system as soon as possible.

They will be patching shortly [1] [1] - https://twitter.com/jacobian/status/514865870649061376

Yep, they did. :)

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

#417
post #341

Earlier quoted context omitted.

I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an environment variable?

Here is a simple c program to demonstrate this. #include #include int main() { setenv("VAR", "() { :;}; echo vulnerable", 0); system("ls"); } #./a.out vulnerable a.out #

That's awesome.

Does system() invoke /bin/sh? Does it look for 'sh' on the path? What are the rules?

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

#418
post #299

Here's how to patch Ubuntu 8.04 or anything where you have to build bash from source: #assume that your sources are in /src cd /src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 0 25);do patch -p0 Not sure if Ubun…

In Debian Lenny you should also do at the end sudo rm /bin/bash && sudo ln -s /usr/local/bin/bash /bin/bash

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

#419
post #299

Here's how to patch Ubuntu 8.04 or anything where you have to build bash from source: #assume that your sources are in /src cd /src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 0 25);do patch -p0 Not sure if Ubun…

I just wanted to say, "Thanks!"

I successfully patched my 8.04 server and passed the test.

I used sudo ./configure --prefix=/usr --bindir=/bin --sbindir=/sbin --sysconfdir=/etc && sudo make && sudo make install after retrieving and patching the bash build files.

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

#420
post #299

Here's how to patch Ubuntu 8.04 or anything where you have to build bash from source: #assume that your sources are in /src cd /src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 0 25);do patch -p0 Not sure if Ubun…

need to wget all the patches including #26 to fix the 2nd bug reported. instead why not just wget the whole dir of patches..

wget -r 1 -nH -nd -np http://ftp.gnu.org/gnu/bash/bash-4.3-patches/ && rm \\.sig index.html cd bash-4.3; for i in ../bash43-*; do patch -p0 etc

Post reply on HN