The Bash bug has kept Linux and UNIX administrators busy deploying a half-dozen patches, worrying about numerous Shellshock exploits in the wild, and a laboring over a general uncertainty that the next supposed fix will break even more stuff.
Researcher Michal Zalewski, a longtime bug-hunter, has been front and center on some of the Bash research and last week said he had found two additional bugs in the Bourne Again Shell, details of which he’d kept to himself until yesterday.
Zalewski took the wraps off the vulnerabilities, one of which, CVE-2014-6278, mimics the original vulnerability reported Sept. 24 but affects only systems patched against the original Bash vulnerability, CVE-2014-6271.
“Systems that relied solely on the original fix will be vulnerable to attacks and need to be updated again,” Zalewski said, adding however, that systems running a patch released by Red Hat engineer Florian Weimer should be immune.
Like the original vulnerability, CVE-2014-6278 allows an attacker to remotely drop executable code by exploiting a weaknesses in environment variables in Bash, which is the most common command line shell used by Linux, UNIX and Mac OS X servers.
“The internal parser invoked by bash to process the specially encoded function definitions passed around in environmental variables had a small problem: it continued parsing the code past the end of the function definition itself – and at that point, flat out executed whatever instructions it came across, just as it would do in a normal bash script,” Zalewski explained on his lcamtuf blog. “Given that the value of certain environmental variables can be controlled by remote attackers in quite a few common settings, this opened up a good chunk of the Internet to attacks.”
A simple test, Zalewski said, would be to run the following code from a Bash shell:
_x='() { echo vulnerable; }’ bash -c ‘_x 2>/dev/null || echo not vulnerable’
Zalewski’s second bug, CVE-2014-6277, is less interesting than his other vulnerability, he said.
“CVE-2014-6277 is an exploitable memory corruption bug that alters the internal state of the program and can be turned into an exploit that permits remote code execution,” Zalewski said. “It is perhaps less ‘interesting’ than the other find, CVE-2014-6278, because it requires a degree of finesse to leverage in an attack – certainly more than [CVE-2014-6278] or the original bug.”
The original Bash vulnerability has now been public for more than a week, though some were given a two-week head start under embargo. While Linux distributions pushed patches out the door fairly quickly, there were immediate suspicions—which were confirmed—that the patches were incomplete. Fellow Google researcher Tavis Ormandy uncovered the first problem in the original patch that could be exploited in limited circumstances, Zalewski said. Immediately a new CVE was issued, CVE-2014-7169, and new patches developed. Weimer and Todd Sabin of Red Hat then uncovered a buffer overflow vulnerability that would be difficult to exploit, again resulting in a new identifier, CVE-2014-7186. Another bug, CVE-2014-7187, was then uncovered by Weimer and Sabin, again difficult to exploit, Zalewski said.
Patches from Bash maintainer Chet Ramey and Weimer were released that stemmed the tide against a number of publicly disclosed exploits that were in circulation. All of this happened within 48 hours of the first Bash disclosure and in advance of an anticipated patch from Apple for three versions of OS X, all of which were possibly incomplete as well.
“At that point, Florian’s patch seemed just like a good idea (and had been adopted by some Linux distributions as a defense-in-depth), but we had no conclusive evidence that people who have used just the original fix (or the followup fixes for CVE-2014-7169) are vulnerable to any specific, comparably serious bugs,” Zalewski said.
Shellshock, like Heartbleed before it, has Internet-wide consequences and poses a number of patching challenges because so many hidden functions rely on Bash. A number of security companies have reported exploit code in the wild, some of it harvesting bots for DDoS attacks, while others are merely trying to comprehensively enumerate the number of vulnerable systems without much luck.
“All remote code execution vulnerabilities essentially permit the attacker to take control of the affected systems. Less ambitious attackers may leverage them just to take control of a large number of systems to use in a DDoS attack and settle for that, but there is nothing about the underlying bash bugs that makes them uniquely suited for the job,” Zalewski said. “The defining characteristics of the original bash bug are that it affected a very significant number of systems and that it could be exploited with remarkably serious consequences in an unusually simple way. It is also somewhat unusual in that it cropped up in an unexpected place.”
The Bash vulnerability’s ubiquity has also upped the ante and will likely inspire further scrutiny of other core infrastructure.
“The tricky part about this bug is that nobody was expecting that bash may be doing complex parsing of environmental variables, so we didn’t even have this attack surface mapped out,” Zalewski said. “In contrast to this, everybody is worried about the next big bug in OpenSSH, Apache, OpenSSL, etc.”
