from Hacker News

3rd Shellshock Vulnerability Found

by propercoil on 9/26/14, 3:45 PM with 42 comments

• by skuhn on 9/26/14, 4:28 PM

  This is not a vulnerability, it is intended functionality. Some scripts undoubtedly depend on overloading a shell builtin command with a function (even though it is gross).

  The post's proposed exploit path is not possible on Linux and most OS's, because you cannot have a setuid script.[1]

  [1] http://unix.stackexchange.com/questions/364/allow-setuid-on-...

• by lambda on 9/26/14, 5:36 PM

  If you're vulnerable to this, then you're vulnerable to someone setting PATH and changing all executables that you refer to.

  That's not the "shock" part of "shellshock"; that's a long known issue. Applications which pass arbitrary variables from the network through environment variables already add a unique prefix to the variables, to prevent this kind of problem. That unique prefix also prevents them from accidentally conflicting with the name of an actual executable for this case.

  Now, there are still going to be bugs with suid executables not sanitizing their environment, but those apply in many other ways, such as via PATH and LD_PRELOAD.

  The "shock" part of shellshock was that it was possible to execute arbitrary code, upon just loading a variable in Bash, regardless of what its name was, depending only on the contents, which in many cases can be attacker controlled.

• by mzs on 9/26/14, 4:35 PM

  Wow this is getting out of hand, that's not really a security vulnerability anymore. That's how bash passes exported functions, I'll get back to that.

  There is some misunderstanding though regarding the suid shell script. I can't think of any modern unix other than solaris that allows those by default any more. It's just not a concern anymore unless an admin twiddles some sysctl or what not. And in the case of solaris /bin/sh is not bash. Also /bin/sh does it's own setuid after comparing to 100 (unless the -p option is passed) so often if people are not adding users to a group or sudo, they would create a ksh or perl script instead. Anyway that's just rambling, sorry, the short answer is that I would be really surprised if there was any modern system that used bash as /bin/sh and also allowed suid interpreter scripts.

• by acqq on 9/26/14, 4:27 PM

  It's actually not "new" it's a "feature" that everybody became aware it existed since long ago only once Shellshock bug became known.

  Christos Zoulas from NetBsd has the arguments that I really like: it's a "feature" that was widely unknown and that should be disabled by default:

  http://openwall.com/lists/oss-security/2014/09/25/31

• by acdha on 9/26/14, 4:35 PM

  Can we go straight to the part where this is disabled behind a --insecure flag and everyone can spend a release cycle migrating untrusted input handling to languages which were designed for it?

• by schrodingersCat on 9/26/14, 4:03 PM

  I just tried this in zsh 5.0.6 (x86_64-apple-darwin13.3.0). It reports vulnerable as well.

  edit: Yes, this feature works when formatted correctly for zsh as "function ls () { echo vulnerable }". However, I was wrong in that zsh -c will not run the function (of course running "ls" in the same session will). I'm going to call this not a problem.

  edit: When trying this one-liner in zsh: "env x='() { :;}; echo vulnerable' zsh -c 'echo hello'" (as suggested by https://superuser.com/questions/816622/does-the-shellshock-b...), the output indicates my shell is vulnerable. Could someone please try and replicate?

• by rootbear on 9/26/14, 4:58 PM

  If this is how passing functions is supposed to work in bash, then why do I get different results, depending on which system I'm on? I've been madly patching my systems since yesterday and on a RHEL 6.5 system I get a different result than from an Ubuntu 12.04 system:

      [RHEL-6.5 tmp]$ uname -a
      Linux hostname1 2.6.32-431.23.3.el6.x86_64 #1 SMP Wed Jul 16 06:12:23 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
      [RHEL-6.5 tmp]$ bash --version
      GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
      [RHEL-6.5 tmp]$ ls
      file1  file2  file3
      [RHEL-6.5 tmp]$ env ls='() { echo vulnerable; }' bash -c ls
      file1  file2  file3
  
  
      Linux hostname2 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
      Ubuntu 12.04:~/tmp$ bash --version
      GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
      Ubuntu 12.04:~/tmp$ ls
      file1  file2  file3
      Ubuntu 12.04:~/tmp$ env ls='() { echo vulnerable; }' bash -c ls
      vulnerable
  

  Is this a basic difference in the feature sets of Bash 4.1 and Bash 4.2? Like several posters, I was unaware of this feature and have certainly never used it. Perhaps it should be off by defaults? How big of a mess would that make? I would also like to see more distributions use something other than bash as /bin/sh, but that's another discussion, I guess.

• by dahjelle on 9/26/14, 4:12 PM

  If I'm looking at this correctly, it appears that the Red Hat patches aren't vulnerable to this particular vulnerability. (I believe they patched bash differently than upstream, as per https://securityblog.redhat.com/2014/09/26/frequently-asked-...)

  EDIT: I tested on CentOS 6.5 and Fedora 18 (for which we'd manually backported the Fedora 19 patches).

• by ufo on 9/26/14, 6:30 PM

  I know this is not really an issue but is there any use for this "function exporting" feature in the first place? I had never heard about it before and when I did it kind of sounded like an ugly hack.

• by Eclyps on 9/26/14, 4:16 PM

  I was not able to replicate this on Amazon's linux distro after the second patch was applied. After only the first patch, though, the server was still vulnerable.