The recent few days have been hectic for everyone who works in the Linux/Unix world. Bash security flaws have rocked the globe leaving people confused, worried, or just frustrated. Now that the storm is over and patches are available for most operating systems, here are the answers to some of the common questions we’ve been asked:
Why are there four CVE assignments?
The original flaw in Bash was assigned CVE-2014-6271. Shortly after that issue went public a researcher found a similar flaw that wasn’t blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. 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.
Is CVE-2014-7169 the same severity as the original flaw?
Our research, and that of others, shows that it would not have been possible to exploit the CVE-2014-7169 flaw remotely in the same way that it was for the previous flaw. So, even though there were security consequences of the CVE-2014-7169 flaw, it was certainly not as severe as the original flaw.
Why did Red Hat delay in providing a patch for CVE-2014-7169?
When a second issue with Bash was found a few minutes after the first one went public, we knew there was something wrong. We could have followed a duct-tape approach and issued patches to our customers quickly or we could have done this correctly. Applying multiple security updates is extremely difficult!
When CVE-2014-7169 went public, there was a lot of visible confusion around how to address this issue. This was fueled by the media and by the fact that exploits were immediately available on the Internet.
Red Hat carefully analyzed the root cause of the issue and wrote and tested patches. We posted these patches to the community for review and allowing everyone to freely use them if they wanted to. Doing things correctly takes time!
Why is Red Hat using a different patch then others?
Our patch addresses the CVE-2014-7169 issue in a much better way than the upstream patch, we wanted to make sure the issue was properly dealt with.
I have deployed web application filters to block CVE-2014-6271. Are these filters also effective against the subsequent flaws?
If configured properly and applied to all relevant places, the “() {” signature will work against these additional flaws.
Does SELinux help protect against this flaw?
SELinux can help reduce the impact of some of the exploits for this issue. SELinux guru Dan Walsh has written about this in depth in his blog.
Are you aware of any new ways to exploit this issue?
Within a few hours of the first issue being public (CVE-2014-6271), various exploits were seen live, they attacked the services we identified at risk in our first post: from dhclient, CGI serving web servers, sshd+ForceCommand configuration, git repositories. We did not see any exploits which were targeted at servers which had the first issue fixed, but were affected by the second issue. We are currently not aware of any exploits which target bash packages which have both CVE patches applied.
Why wasn’t this flaw noticed sooner?
The flaws in Bash were in a quite obscure feature that was rarely used; it is not surprising that this code had not been given much attention. When the first flaw was discovered it was reported responsibly to vendors who worked over a period of under 2 weeks to address the issue.
Did you have an outage?
Our security blog article was widely regarded as the definitive source of information about the flaw, being referenced in news articles, on Wikipedia, and from organizations such as US-CERT. This caused more demand than we expected so we did have some periods on Thursday where the blog was unavailable. Our customer portal also had some problems keeping up with demand at times. Many of the issues we saw have already been corrected.
Is my lightbulb really affected by these flaws?
Only if your lightbulb runs Bash! Lots of press have latched onto the fact that this flaw could affect the Internet Of Things, allowing attackers to take control of your systems via home appliances. In reality, embedded devices rarely use Bash, going for more lightweight solutions such as BusyBox, which includes the ash shell that was not vulnerable to these issues. So while it’s certainly plausible that some devices may be affected by this flaw, it won’t be very common.