4 ms·

Note that this will affect devices without listening services. Embedded devices are very likely to be affected for a long time. A note for those trying to repr

• makomk 12y ago
  Thankfully embedded devices are less likely to have bash installed than desktop or server systems, or this would be quite nasty.
  • tdicola 12y ago
    Are smaller shells like busybox affected though? I bet a lot of routers run it (I know mine with OpenWRT does).
    • jeffmcjunkin 12y ago
      No, busybox is not affected.
    • masklinn 12y ago
      The problem is very specific to bash and bash only (a hacky feature via environment variables so shells can inherit their parent's functions)
  • jeffmcjunkin 12y ago
    Very true. To be clear to other readers, busybox is more common in smaller embedded devices, though today's AlienVault blog post [1] showed that Mitel VoIP systems (which use Debian/ARM, if I recall) use bash and are vulnerable. [1] http://www.alienvault.com/open-threat-exchange/blog/attackers-exploiting-shell-shock-cve-2014-6721-in-the-wild http://www.alienvault.com/open-threat-exchange/blog/attacker...
    • dfc 12y ago
      The default /bin/sh in Debian is dash.
• arielby 12y ago
  Note that if you try to do the exploit via the hostname or another common option, the CVE-2011-0997 fix will stop you. However, the fix is incomplete - it does not check all options, only the ones the old CVE's fixers thought of.
• lambda 12y ago
  I reproduced it with dnsmasq as well; just set up a server with the following options. eth2 is the network adapter that I was using for the test network, and I picked the 10.0.10.0/24 prefix for this particular network. interface=eth2 dhcp-range=10.0.1.100,10.0.10.200,12h dhcp-option-force=114,() { :; }; echo "hi" Then on the target system (an Ubuntu system using ifupdown for configuration), I just configured eth0 for dhcp: iface eth0 inet dhcp and ran: sudo ifdown eth0 && sudo ifup eth0 Unlike some of the other exploits, this one affects Debian and Ubuntu. Debian and Ubuntu use dash as /bin/sh, so many things that just use /bin/sh (such as the system() function, lots of shell scripts, etc) aren't affected like they are on other Linux distros. But dhclient calls dhclient-script to execute various hook scripts, and dhclient-script uses #!/bin/bash and is thus vulnerable. On my particular Debian system, it doesn't look like NetworkManager based DHCP is affected, as it doesn't call the dhclient-script. It does call various scripts in /etc/network/if-*.d/, but none of the ones that I have installed use bash, they all use sh. However, if I deliberately put a bash script in there, and attach it to the network with the rogue DHCP server, it does get passed the bad environment variable (though on my Debian system I've already updated Bash so I just get the error message rather than the exploit). So yeah, there are a a lot of ways for a stray Bash script to cause problems here.
  • fulafel 12y ago
    Did you try if you can do something else beside the echo on Ubuntu? dhclient runs under an AppArmor profile which tries to keep it in a pretty short leash.
    • lambda 12y ago
      No, I didn't try that, but we happen to be running a custom kernel that doesn't include AppArmor support, as we needed to pull in a newer upstream kernel version. Given this issue, we should probably revisit that decision.
    • sploitfun 12y ago
      Nope dhclient running under apparmor profile is still vulnerable. I was able to execute linux commands like rm, wget, chmod...
• noselasd 12y ago
  You could probably exploit it via e.g. USB too. A lot of shell scripts get run when you plug in an USB device - And I'm sure you can cram the exploit into one of the device strings that the host queries for.