Our servers are not vulnerable to the bug in “bash”
We’ve had a couple of people ask if our servers are vulnerable to the recent security bug in the bash shell, also known as the “shellshock” bug.
The answer is no. All copies of bash on all our servers were updated to a fixed (patched) version yesterday, within an hour of the news becoming public.
Update September 25, 2:58 PM: We’ve also applied a later, stronger version of the fix today. This will soon be announced as Debian Security Advisory DSA-3035-1 .
on Thursday, September 25, 2014 at 10:08 am (Pacific) A. Customer wrote:
Good to know and relieved to find this blog post! The target space for this one is crazy big.
Thank you tigertech!
on Thursday, September 25, 2014 at 6:49 pm (Pacific) Marcus Tibesar wrote:
I heard that the patch is a partial solution and is not a final fix. Is that true?
on Friday, September 26, 2014 at 9:38 am (Pacific) Robert Mathews wrote:
Marcus Tibesar wrote:
>I heard that the patch is a partial solution and is not a final fix. Is that true?
Well, the first patch fixed all the problems known at that time. People later discovered an additional way to exploit the bug after the initial patch, so a second patch was released. We also applied that second patch immediately, as described in the update to the post. The second patch appears to be a comprehensive final fix.
Technical details: The second patch completely removes bash’s ability to parse arbitrary variable names as functions, instead only parsing them if they’re prefixed with “BASH_FUNC_” and suffixed with “()” (Debian used the same patch as Fedora). This ensures that bash will no longer parse a function in a variable named something like “HTTP_USER_AGENT”, whether it’s malicious or not. As an example, this:
env 'HTTP_USER_AGENT=() { echo Imported environment variable;};' \ bash -c 'HTTP_USER_AGENT'… used to print “Imported environment variable”. That’s not malicious, but you can see that bash used to parse any arbitrary variable name, which is at the heart of the problem. That no longer works. You’d now need to exactly specify the variable’s name, as well as the content, like:
env 'BASH_FUNC_HTTP_USER_AGENT()=() { echo Imported environment variable;};' \ bash -c 'HTTP_USER_AGENT'Since web servers won’t usually let remote users control the names of exported variables — in fact, our servers explicitly strip any variable that doesn’t begin with “HTTP_” — a remote attacker can’t exploit any remaining hidden bugs in the parsing of imported functions.