Shellshock a Fail for Security Disclosure
Shellshock and the Xen vulnerability. One of these things is not like the other, and an expert says they can teach us a lot about how to disclose security vulnerabilities.
TORONTO: At the annual SecTor Toronto security conference, one of the key highlights for the last several years has been the Fail Panel, which examines the areas where the security industry did not succeed and where lessons of the past have still not been learned.
This year was no exception. At the 2014 edition of the Fail Panel, the major topic of discussion was the big brand-name vulnerabilities like Heartbleed, Shellshock and POODLE and how they are properly -- or in some cases improperly -- disclosed.
Securosis CEO and analyst Rich Mogull took particular aim at the Shellshock vulnerability and how it was disclosed. Shellshock is technically a vulnerability in the BASH (Bourne Again Shell) that could have enabled an attacker to inject and execute arbitrary commands on a vulnerable server.
Mogull noted the way that the Kaminsky DNS vulnerability was disclosed in 2008. After security researcher Dan Kaminksy found a serious security flaw in DNS, he proceeded to work with leading IT vendors to patch the issue, Mogull recounted. Two weeks passed between the time that Kaminsky first found the vulnerability and talked to vendors about the issue and when the issue was publicly disclosed.
Shellshock's Disastrous Disclosure
Now contrast that to Shellshock, Mogull said. Linux vendor Red Hat reported that it was patching the BASH flaw, and the effort was not well coordinated. The initial patch didn't cover the entire attack surface, and there were at least six different ways to exploit the BASH flaw. To add further insult to injury, the open-source Metasploit penetration testing framework rapidly made attack signatures available.
"The level of communications screw-ups on Shellshock were unbelievable considering everything that we have learned about disclosure in the past 10 years," Mogull said. "There appeared to be no coordination among the UNIX guys and maybe someone jumped the gun."
In Mogull's view, most organizations did not have the time to patch before the Shellshock attacks started to happen. Going a level deeper, he emphasized that Shellshock was a non-trivial vulnerability to defend against.
"Even though you might have though you could block it (Shellshock) on the surface, there are several ways that other applications interact," Mogull said. "It was a fricking disaster."
Xen Project Gets It Right
Although he considers the Shellshock disclosure a failure, Mogull said there are good recent examples of how disclosure can be done the right way.
"Contrast that (Shellshock) with the massive Xen vulnerability that could have destroyed every cloud service," Mogull said. "It was all fixed before anything went public."
The open-source Xen virtualization project on Oct. 1 publicly disclosed a critical vulnerability that could have enabled an attacker to read data from other virtual machines on the same host server. The flaw triggered reboots at Amazon, Rackspace and IBM Softlayer to fix the issue, all before the vulnerability was made public.
"I believe that you don't go with with full disclosure until there is an opportunity to fix," Mogull said. "The cycle to spin up attacks is short, so if we're not given an opportunity to patch we can't keep up."
Sean Michael Kerner is a senior editor at eSecurityPlanet and InternetNews.com. Follow him on Twitter @TechJournalist.