Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Re: CVE-2014-6271 – remote code execution through bash

seclists.org

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Re: CVE-2014-6271 – remote code execution through bash

#11

Post by dperfect »

89vision wrote: post #9
Thesaurus wrote: post #6

Earlier quoted context omitted.

I just patched my CentOS 6 server a few hours ago. Double check yum.

I patched mine about 10 hours ago. Is this one newer?

Make sure you have bash-4.1.2-15.el6_5.2 instead of bash-4.1.2-15.el6_5.1 which was the initial patch.

Re: Re: CVE-2014-6271 – remote code execution through bash

#13

Post by bodyfour »

tokenizerrr wrote: post #10
rbobby wrote: post #8

Not having worked with bash (et al) in ages I wonder whether allowing a function definition (even without trailing commands) is not still hole? What if you defined a function 'ls() { evil... }'... could a CGI script making a call to 'ls' actually end up with the function instead of the real 'ls'?

Yes, but if you can control enviroment variable names then you can also set LD_PRELOAD and a whole load of other nasty enviroment variables.

...although some programs blacklist unsafe environment variable names. They all should be updated to also blacklist bash function values.

Re: Re: CVE-2014-6271 – remote code execution through bash

#14

Post by psgbg »

mrmondo wrote: post #4

Debian patched this 8 hours ago, Redhat issued a patch about 3 hours ago, I believe Centos is still vulnerable, Ubuntu 14.10 isn't patched yet, Ubuntu 14.04 was patched about 3 hours ago.

I'm using debian jessie (testing) i386, and I had to download bash myself (from sid) because my up-to-date system was affected but the first patch was available for sid (unstable) and wheezy (stable) and not in jessie.

So I don't know if every architecture, and version is updated with the same speed.

Re: Re: CVE-2014-6271 – remote code execution through bash

#15

Post by Turbo_hedgehog »

If you have some RHEL4 machines that you still haven't retired:

wget https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.2.el4...

rpm -ivh bash-3.0-27.0.2.el4.src.rpm

rpmbuild -ba /usr/src/redhat/SPECS/bash.spec

rpm -Uvh /usr/src/redhat/RPMS/x86_64/bash-3.0-27.0.2.x86_64.rpm

Re: Re: CVE-2014-6271 – remote code execution through bash

#16

Post by ak217 »

rbobby wrote: post #8

Not having worked with bash (et al) in ages I wonder whether allowing a function definition (even without trailing commands) is not still hole? What if you defined a function 'ls() { evil... }'... could a CGI script making a call to 'ls' actually end up with the function instead of the real 'ls'?

You can't control the name of the function - that's dictated by the name of the environment variable. The feature at fault is activated by the presence of "(){" at the start of the environment variable value.

Re: Re: CVE-2014-6271 – remote code execution through bash

#17

Post by mh- »

bodyfour wrote: post #13
tokenizerrr wrote: post #10

Earlier quoted context omitted.

Yes, but if you can control enviroment variable names then you can also set LD_PRELOAD and a whole load of other nasty enviroment variables.

...although some programs blacklist unsafe environment variable names. They all should be updated to also blacklist bash function values.

fortunately, sudoers(5) (et al.) whitelist certain variables.

Re: Re: CVE-2014-6271 – remote code execution through bash

#18

Post by cft »

This appears to be the same as http://seclists.org/oss-sec/2014/q3/att-690/eol-pushback.pat... at least for 4.3. But for 3.2 http://seclists.org/oss-sec/2014/q3/att-690/eol-pushback.pat... did not work, I had to download bash32-053.bin from Chet's email.

Procedure for Ubuntu 8.04 and other installations where binaries are not available (default 8.04 LTS server did not have m4 and bison dependencies), assuming that 1st patch has already been applied per https://news.ycombinator.com/item?id=8364385 :

  #Executing as root 
  #assume your sources are in /src:
  cd /src/
  echo "getting m4..."
  wget http://ftp.gnu.org/gnu/m4/m4-latest.tar.gz
  tar zxvf m4-latest.tar.gz 
  cd m4-1.4.17/
  ./configure && make && sudo make install
  cd /src/
  echo "getting bison..."
  wget http://ftp.gnu.org/gnu/bison/bison-3.0.tar.gz
  tar zxvf bison-3.0.tar.gz 
  cd bison-3.0
  ./configure && make && sudo make install
  echo "getting patch..."
  cd /src/
  #replace line below with wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-026 tomorrow
  wget http://seclists.org/oss-sec/2014/q3/att-690/eol-pushback.patch
  cd bash-4.3
  patch -p0

Re: Re: CVE-2014-6271 – remote code execution through bash

#19

Post by stormbrew »

rbobby wrote: post #8

Not having worked with bash (et al) in ages I wonder whether allowing a function definition (even without trailing commands) is not still hole? What if you defined a function 'ls() { evil... }'... could a CGI script making a call to 'ls' actually end up with the function instead of the real 'ls'?

I think the cases where it's still a hole are probably obscure and/or unlikely in the wild, but I definitely think the response to this should have been to disable the feature altogether. It's a terrible idea and I'm really curious if anything actually uses it and should be using it.
Post reply on HN