6 ms·

I generally agree with this, but I do have a few nitpicks. > Comparing this to Heartbleed is pretty absurd They're such different bugs that they're hard to co

I generally agree with this, but I do have a few nitpicks. > Comparing this to Heartbleed is pretty absurd They're such different bugs that they're hard to compare. Heartbleed definitely affected more high-value targets, however the exploit just gave you some RAM contents. It would still be some manual work to figure out what those values meant (whcih bits are ssh keys, which are passwords, ...) and leverage them. Shellshock is much better suited for a "sweep all of IPv4, build a botnet" scriptkiddie attack. > bash CGI in particular are basically unheard of The CGI doesn't have to be written in bash, it just has to call something that calls something that ends up calling system()/popen()/whatever. There are probably lots of such cases. Once httpd puts the poisonous string in your environment it's going to be passed down to all of your subprocesses. If you're using CGI at all on a machine with /bin/sh==bash you should assume you're vulnerable. > They live on controlled networks where rogue DHCP servers can't be operated. If you're on a network with nodes you don't trust (public wifi, large corporate networks, etc) there is a risk that machines other than the router will reply to broadcast DHCP requests. I don't know the full scope of this attack vector yet but I wouldn't be blasé about it.

skuhn 12y ago
> They're such different bugs that they're hard to compare. I mentioned it because people are having a field day comparing the two (which results in some good old fashioned fear mongering). A random sampling: CNet: 'Bigger than Heartbleed' Gizmodo: Why the Bash Shellshock Bug Could Be Even Worse Than Heartbleed Mashable: Shellshock: The 'Bash Bug' That Could Be Worse Than Heartbleed The Independent: Shellshock: Bash bug 'bigger than Heartbleed' could undermine security of millions of websites Errata Security: Bash bug as big as Heartbleed > The CGI doesn't have to be written in bash This was covered in my second item, about using system(). I'm certain that there is software out there that does this, but it is in no way common or has ever been best practice. The panic over this presumes that people use CGI all the time. It's awful, it's always been awful, and should never be used for anything public facing for lots of other reasons. Note that FastCGI is not impacted. > If you're on a network with nodes you don't trust Correct, but this isn't the case for most (but not all) server deployments. In your own datacenter environment, you control the network and all of the hosts on it -- if someone busts in to run a DHCP server, you have bigger fish to fry.

skuhn 12y ago

> They're such different bugs that they're hard to compare. I mentioned it because people are having a field day comparing the two (which results in some good old fashioned fear mongering). A random sampling: CNet: 'Bigger than Heartbleed' Gizmodo: Why the Bash Shellshock Bug Could Be Even Worse Than Heartbleed Mashable: Shellshock: The 'Bash Bug' That Could Be Worse Than Heartbleed The Independent: Shellshock: Bash bug 'bigger than Heartbleed' could undermine security of millions of websites Errata Security: Bash bug as big as Heartbleed > The CGI doesn't have to be written in bash This was covered in my second item, about using system(). I'm certain that there is software out there that does this, but it is in no way common or has ever been best practice. The panic over this presumes that people use CGI all the time. It's awful, it's always been awful, and should never be used for anything public facing for lots of other reasons. Note that FastCGI is not impacted. > If you're on a network with nodes you don't trust Correct, but this isn't the case for most (but not all) server deployments. In your own datacenter environment, you control the network and all of the hosts on it -- if someone busts in to run a DHCP server, you have bigger fish to fry.