Pierluigi Paganini
October 05, 2014
IT community worldwide has been shocked by the discovery of the Bash Bug flaw, a vulnerability that was present in the popular Bash component for more than two decades.
While principal vendors were working to provide the necessary patches for vulnerable Linux and Unix systems, the researcher Michal Zalewski had found two additional bugs in the Bourne Again Shell.
“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 blog post. “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.”
The disconcerting news is that one of two bugs, coded as CVE-2014-6278, as the original vulnerability Bash Bug (CVE-2014-6271) could be exploited for remote arbitrary code execution, but it exists because of an incomplete fix for CVE-2014-6271, CVE-2014-7169, and CVE-2014-6277 as explained in the official definition.
“GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary commands via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271, CVE-2014-7169, and CVE-2014-6277.” states the definition published on Mitre.org.
This means that systems that have been fixed only for the original bash bug are still vulnerable to remote hacking. Zalewski explained that it is easy to test our system running the following code from a Bash shell:
_x=’() { echo vulnerable; }’ bash -c ‘_x 2>/dev/null || echo not vulnerable’
Zalewski also discovered a second memory corruption bug in the Bash, it is coded as CVE-2014-6277 and seems to be less severe respect the first one. Also in this case the attacker exploiting the flaw can execute arbitrary code or cause a denial of service,
“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.”
Many experts had suspicions that the first wave of patches, released to solve the Bash Bug, was incomplete, and unfortunately they were right, immediately a new CVE was issued, CVE-2014-7169, and new patches developed.
Experts at Red Hat Todd Sabin and Florian Weimer then uncovered a buffer overflow vulnerability that would be difficult to exploit, coded as CVE-2014-7186. Another bug, CVE-2014-7187, was later uncovered by Weimer and Sabin, again difficult to exploit, Zalewski said.
“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.
The principal problem related patching management for the Shellshock bug it related the huge amount of hidden functions which rely on Bash and that are present in numerous devices ordinarily exposed on the Internet. The principal security firms have reported exploit code in the wild, fortunately in the majority of the cases the attacker were only enumerating the number of vulnerable systems without compromising them.
Michal Zalewski made an interesting reflection on the Bash Bug case, in the future security experts and bug hunters may discover other vuònerabilities in core infrastructure with serious repercussions under the security perspective.
“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.”
(Security Affairs – Bash Bug, Shellshock)
