Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched

Binary releases are here: https://github.com/ido/macosx-bash-92-shellshock-patched/rel... ...including a .pkg file that can be installed with a double-click.

Instruction here: https://github.com/ido/macosx-bash-92-shellshock-patched/blo...

Pull requests are welcome, especially if you've modified Florian's patch to apply cleanly on 3.2, which is my next task.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID:	Ubuntu
  Description:	Ubuntu 12.04.3 LTS
  Release:	12.04
  Codename:	precise
  $ dpkg -l bash | tail -1
  ii  bash                              4.2-2ubuntu2.5               GNU Bourne Again SHell
  $ foo() { echo foo; }
  $ export -f foo
  $ env | grep BASH_FUNC
  BASH_FUNC_foo()=() {  echo foo

Probably as of about 13:27 UTC yesterday, if I'm reading correctly here: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise...

Edit: Confirmed in this bugzilla ticket comment https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c51

  $ hardening-check  /bin/dash /bin/bash
  /bin/dash:
   Position Independent Executable: yes
   Stack protected: yes
   Fortify Source functions: yes (some protected functions found)
   Read-only relocations: yes
   Immediate binding: yes
  /bin/bash:
   Position Independent Executable: no, normal executable!
   Stack protected: yes
   Fortify Source functions: yes (some protected functions found)
   Read-only relocations: yes
   Immediate binding: no, not found!

  zx2c4@krantz ~ $ hardening-check /bin/bash
  /bin/bash:
   Position Independent Executable: yes
   Stack protected: yes
   Fortify Source functions: yes
   Read-only relocations: yes
   Immediate binding: yes

(There's no guarantee that dash doesn't have similar problems, but at least the surface area is smaller.)

I'm quite sure that's what happens in DHCP case.

That is definitely a problem, but it's not the only problem. Try running this from /usr/bin (it returns lots of results on Linux Mint, Ubuntu, or Debian):

    grep -nR '#!.*bash' * | grep :1:

    $ x='() { :;}; echo vulnerable' /usr/bin/fakeroot
    vulnerable

  > Given the many eyes now turning towards findings bugs in bash
  > and  building exploits  with them  it might  be safer  to fix
  > those bashisms and switch dhclient-script over to #!/bin/sh.
  >
  > What do you think?

  Actually, if you go that road,  you would need to drop anything
  ever calling  python, perl,  ruby or whatever  language somehow
  remotely. Some scripts might have good reasons to uses bash and
  bashisms (I'm not saying that's the case here, but still).

  What I  find more concerning  is to pass  unchecked environment
  variable directly from remote (or any input, actually).

    What I  find more concerning  is to pass unchecked
    environment variable directly from remote (or any input, actually).

sudo does this to a small extent; it wipes function env vars.

In the rare system/popen my programs do I explicitly give the entire env - just PATH=/bin:/usr/bin; sometimes I give an empty env.

For something like a dhcp client it is obviously bad. The responsibility there is to whatever invokes it.

It is not like there is an alternative python/ruby implementation that is "more robust against software failures" and has DEB_HARDENING turned on. If there was I would totally support going down the road of "making small changes to programs that process data from anyone on the network" so they could run on HardPython.

If there was something like HardPython alternative that was "more robust to software failures" with st

Everyone would think this is the way we would react, but in reality most people go out of their way to prove that these issues are not exploitable first. He spots them straight away with no pride to get in the way. Very professional.

But I do agree, impressive and professional.

https://github.com/hannob/bashcheck

    foo='() { echo not patched; }' bash -c foo

    If the command shows "not patched", you don't
    have the patch. If it shows "command not found",
    you're good.

    cd $(brew --repository)
    git remote add krishicks git@github.com:krishicks/homebrew.git
    git fetch krishicks bash
    git checkout krishicks/bash
    brew upgrade bash

1. https://news.ycombinator.com/item?id=8368272 2. https://news.ycombinator.com/item?id=8368676

Edit: To clarify, after recompiling I would need to manually update it in the future (or switch back to the repositories once they include it). Applying this patch is not a apply-and-forget action. I don't really see the value of applying it myself, especially when I don't connect to public/company/school networks during the weekend.

As well as the test noted here you can check the the changelog in rpm. (sorry don't know how to do it for debian osx ...)

    rpm -q --changelog bash

    #!program

This would fix a lot of this shellshock nonsense and also be a better alternative to the #!/bin/env hack for finding programs at different locations on different systems.

Programs should use args for communicating.

Extended syntax for programs to declare that they really need certain environment variables:

    #!program env=WHITELIST OF ENV VARS ALLOWED

I could propose that the whitelist be parsed before handing to any program. But that would be putting a potentially expensive and difficult job in a higher privileged place.

I think the rest is worth considering though.

  $ env -i WLIST=$WLIST WLIST2=$WLIST2 command

My guess is that the unadorned `ONESHOTENVVAR=1 someprogram` is a little obscure to some. As to the lack of -i; it almost certainly necessary makes no difference to the result.

But for most part, it's probably just people copying-and-pasting stuff without really figuring it out what it does. For example, compare "exploit #1" and the supposedly different "exploit #3" on shellshocker.net.