Bash Bug
Later posts on BashBug/Shellshock:
- Bashbug/Shellshock: The Day After
- Shellshock: how to check and update potentially vulnerable systems
Infosecurity world is on red alert again due to a new vulnerability discovered in all *Nix systems, including Mac OS X. The situation is arguably as serious as it was with the #Heartbleed discovery earlier this year. “Arguably” because while some experts tend to downplay its severity, others claim it is at least as serious as (and probably more dire than) the April “hit” of infosec news outlets and blogs. Welcome, #BashBug, aka #Shellshock.
What’s up?
A technical description: The vulnerability is present in the Bourne again shell simply known as Bash, – a Unix shell written in 1989. It is a default shell on Linux and Mac OS X too, which means that all of these systems are affected.
The flaw, discovered by Stephane Chazelas of Akamai, allows an attacker to remotely attach a malicious executable to a variable that is executed when Bash is invoked.
The US National Vulnerability Database lists the bug as CVE-2014-6271, and its overview reads: “GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code 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.”
#BashBug: is it #Heartbleed 2.0? #security #redalert
Tweet
The problem is a quarter-century old. And since Bash is currently in “pervasive use”, the bug is almost ubiquitous.
A lot of technical details on the bug is available at Securelist now.
What they say?
There is near consensus that the #bashbug is dead serious. The fact that it’s easy to exploit, potentially extremely harmful, and present in nearly every *Nix system makes it a beast of a vulnerability. NVD lists its Exploitability and Impact subscores at 10.0, while Access Complexity is “Low”.
The advisory from Red Hat reads: “This vulnerability CVE-2014-6271 could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue… This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this.”
According to Ars Technica, “If Bash has been configured as the default system shell, it can be used by network–based attackers against servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.”
Security researcher Robert Graham of Errata Security is sure that the #BashBug is as big as Heartbleed, or even more dire.
“An enormous percentage of software interacts with the shell in some fashion,” he wrote. “Thus, we’ll never be able to catalogue all the software out there that is vulnerable to the bash bug. This is similar to the OpenSSL bug: OpenSSL is included in a bajillion software packages, so we were never able to fully quantify exactly how much software is vulnerable.”
Graham also points out that the bug is especially dangerous for Internet-of-things devices like video cameras “because a lot of their software is built from web-enabled bash scripts. Thus, not only are they less likely to be patched, they are more likely to expose the vulnerability to the outside world.”
Also consider that at least some of these old devices are unpatchable, and things start to look ugly.
On the other hand, Rapid7 isn’t jumping on the “Heartbleed 2.0 bandwagon”, stating that the conditions to exploit it are fairly uncommon for remote exploitation:
“Every affected application may be exploitable through a slightly different vector or have different requirements to reach the vulnerable code. This may significantly limit how widespread attacks will be in the wild. Heartbleed was much easier to conclusively test and the impact way more widespread.”
However, refer to this post from Robert Graham, who says that the #Shellshock bug is “wormable”. He has performed some preliminary “light” scans, immediately discovering “about 3000 systems vulnerable just on port 80, just on the root “/” URL, without Host field”. Graham says there’s actually much more. And – red flag! – someone is already using masscan to deliver malware. “They’ll likely have compromised most of the system I’ve found by tomorrow morning. If they using different URLs and fix the Host field, they’ll get tons more.”
Do you hear that ticking clock?
Remote attacks
The biggest question: How easily can the bug be exploited in order to perform remote attacks? Conditions for the exploitation are “fairly uncommon” (Red Hat, by the way, actually lists them). Still, these attacks are quite possible. Wolfgang Kandek, CTO of Qualys, offers one such scenario:
“Bash is very often involved in a networked setup to execute commands and that opens up an interesting attack vector. Imagine a webserver that allows you to ping an IP address (my router at home has that function for example), it will most likely just call the “ping” executable with the argument that you supplied, probably checking whether the argument is formatted correctly as an IP address. With CVE-2014-6271, if you can control the value of an environmental variable given to the shell, you can make the shell run arbitrary commands. Controlling an environmental variable is not that difficult, as a large number of environmental variables are under control of the attacker, such as the settings for the Referer or the UserAgent. Consequently scenarios where a CGI-BIN setup is used to execute commands on the server can be attacked quite easily.”
Patches
Here’s where things become even more complicated. The fix for CVE-2014-6271 was promptly released by Red Hat, but immediately proved to be incomplete [1, 2] and the vulnerability was found to still be exploitable. So a new entry is currently present in NVD – http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169, with incoming patches for it as well. However, those, which already exist, appear to be pointless, making the current situation look like a “compound fiasco”.
Releases of #BashBug patches proved incomplete #security #redalert
Tweet
The new patch is already offered and, most likely due to the severity of the situation, all of the vendors of the affected software will likely release their fixes. Stay tuned and scan the horizon.
Should I panic?
It would be impractical to do so.
Okay, then what?
First of all, check out this tool and use it to check your own servers for the vulnerability. Interestingly, at the time of this article, stats showed that 7362 tests had been run with 749 vulnerabilities found.
It may make sense to still install CVE-2014-6271 patches even though they don’t blast the #BashBug completely: Rapid7 states that the patched packages are more complicated to exploit. So it’s really worth it to check out your package vendor’s sites in order to obtain these updates.
Also Rapid7 says that the unpatchable systems – such as old hardware devices with embedded, or “welded” software – should be hidden behind a firewall. And it should be a big and secure one.
For Apple systems users: The necessary updates and technical details are available here. OS X 10.9.5 (the latest stable release at the moment) ships with Bash v3.2.51.
Conclusion
Apparently there’s a “new” sheriff in town. The vulnerability was there for many years, thus it’s not impossible that someone knew about it way before the disclosure. It’s not certain whether or not it had been exploited. What damage may it inflict, other than irrevocable loss of nerve cells, is uncertain as well, but if Graham is right… well, tomorrow may look grim.
So patch up, people, and use whatever is available now.
Later posts on BashBug/Shellshock:
Tips