My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Shellshock: More details released about CVE-2014-6277 and CVE-2014-6278. Also: Does Windows have a shellshock problem?

Published: 2014-10-06. Last Updated: 2014-10-06 17:12:06 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

Michal Zalewski did publish more details about the two vulnerability he discovered in the aftermath of Shellshock. He used a fuzzer to discover both vulnerabilities, and now published PoC exploits for both. [1]

To check if you are vulnerable, Michal points to this test string:

foo='() { echo not patched; }' bash -c foo

A quick test shows up-to date OS X, CentOS and Ubuntu as not vulnerable.

The first one, CVE-2014-6277, is a more "traditional" use of uninitialized memory. In most cases, this will just cause a crash. However, it can also be exploited to achieve arbitrary code execution. At its core, this is again due to how functions are parsed in environment variables, so this would be exploitable via HTTP requests.

The second one, CVE-2014-6278, is closer to the original shellshock bug. The PoC exploit posted by Michal is:

HTTP_COOKIE='() { _; } >_[$($())] {echo hi mom; id;}' bash -c :

Just like the first bug, the parser is confused as to where the function definition ends, and it executes the code in { }.

Late last week, a blog post about a similar flaw in Windows suggested to some that the Windows shell is vulnerable as well [2]. The vulnerability is however slightly different. It is not passed to other shells spawned from the original one. Also, in Windows, it is even less likely then in Unix to have cgi-bin scripts call a shell directly. The only realistic exploit vector in Windows remain environments like cygwin that install bash on Windows.

[1] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html
[2] http://thesecurityfactory.be/command-injection-windows.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords: shellshock
1 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

I did a before-and-after cygwin test on three versions of Windows (XP, Vista, 7 each running the 32-bit version of cygwin) and the bash problem seems fixed. I used the "foo=" code shown in the item I am replying to. BEFORE said not patched and AFTER said foo was in unknown command.

Diary Archives