3 ms·

As an alternative, make sure that /bin/sh is set to something other than bash. In Debian and Ubuntu it is already set to dash by default. (There's no guarante

• kentonv 12y ago
  Ehh... Plenty of shell scripts explicitly specify bash in order to use its extended features, so this may or may not protect you.
  • takeda 12y ago
    The problem really is with calls like system("command") which ultimately translate to: '/bin/sh -c "command"'. I'm quite sure that's what happens in DHCP case.
    • plorg 12y ago
      In most cases dhclient scripts are written in bash. In any case they are executed by dhclient-script, the shebang of which - at least in Ubuntu - calls for it to be executed by /bin/bash for the specific reason that the maintainer did not want to rewrite out bash-isms when the default system shell was switched to dash.
    • deleted 12y ago
      [deleted]
    • nitrogen 12y ago
      The problem really is with calls like system("command") which ultimately translate to: '/bin/sh -c "command"'. 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: Just as a random example, on an unpatched Debian wheezy system /usr/bin/fakeroot is vulnerable: $ x='() { :;}; echo vulnerable' /usr/bin/fakeroot vulnerable
    • dfc 12y ago
      Unfortunately this is not the case in debian. There is an open bug to replace bash with dash. There do not seem to be many bashisms in the actual script. Sadly a member of the security team did not seem to be persuaded by the utility of the switch: > 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). [1]: dhclient-script uses bash, allowing remote bash exploits / https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762923 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762923
      • emmelaich 12y ago
        What I find more concerning is to pass unchecked environment variable directly from remote (or any input, actually). You can understand the opinion to an extent because it would require the every program to know in every case what variables are needed and what they're supposed to look like. 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.
        • dfc 12y ago
          My complaint with the response was the "if you go down that road" response. The bug submitter was not suggesting dropping shell scripts, it was a request to remove the bashisms from dhclient so that it could work with dash. 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
• davidgerard 12y ago
  Ten years later, there are still bashisms and explicit calls to /bin/bash lurking in Debian/Ubuntu (e.g. dhclient). So no, you gotta update bash.