The good news about the rapid, industry response to the revelations about exploitable security holes in GNU Bash (Bourne Again Shell) (aka “Shellshock”) is that Linux users had a fix in hand almost as soon as they became aware of the problem those patches addressed.
The bad news about the quick fixes for the two issues, CVE-2014-6271 and CVE-2014-7169, from the likes of Red Hat, Ubuntu, Debian and others is that – in being early- they fail to fix the problems we don’t yet know about. And that’s what we’re seeing in the wake of last week’s storm of patches: a steady drip-drip of disclosures that suggest that Bash may contain other problems worthy of new fixes.
Within hours of the disclosure of the first holes, there were problems discovered by Red Hat Product Security researcher Todd Sabin, who found additional “off by one” errors in Bash that were assigned CVE-2014-7186 and CVE-2014-7187 and warranted a separate patch from Red Hat. At the time, Red Hat warned that “it’s possible that other issues will be found in the future and assigned a CVE designator even if they are blocked by the existing patches.”
And so it was, over the weekend, that noted security researcher Michal Zalewski wrote on his blog that ongoing testing of Bash had discovered what he described as a “new parsing issue…that is almost certainly remotely exploitable.” That issue has been assigned yet another unique identifier: CVE-2014-6277. And, soon after, Zalewski reported another (sixth) vulnerability that he described as “the most severe issue so far, essentially permitting very simple and straightforward remote code execution.” That issue has been assigned CVE-2014-6278.
Details are expected to follow, but on Sunday Zalewski warned that those who are just using the first Bash patch “will soon be in trouble.” U.S. CERT issued a warning following Zalewski’s disclosure warning that, on Shellshock, “we are not done yet.”
The underlying issue with Bash may be that “it’s simply obsolete code,” wrote Robert Graham on the Errata Security Blog on Saturday. “We have modern objective standards about code quality, and bash doesn’t meet those standards.”
Graham’s analysis of Bash’s underlying code reveals a wealth of poor coding practices, from the indiscriminate use of global variables to a heavy reliance on functions like strcpy() which is linked to exploitable code vulnerabilities like buffer overflows.
Beyond that, the legacy code (more than two decades old) contains features that make it more difficult to audit Bash as a whole, Graham notes.
It is also likely that the problems discovered in Bash won’t be limited to Bash, said Chris Wysopal, the CTO of Veracode. With Shellshock coming in the immediate aftermath of the Heartbleed vulnerability, the vulnerabilities of all manner of open source packages are coming under scrutiny. Some of the most venerated of those may ultimately turn out to have the most problems.
“Longevity tends to build trust,” he said. “Certainly with Apache and SSH, you have long-lived projects that are so critical that people have really banged on them,” he said. “But once you’re outside of that top 20 or so projects, the level of attention really falls off.”
