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.
First of all, it's Bourne shellcode and bash has extensions to it. Second of all, whether the programming language is bad or not is totally not relevant. It's the parser in the shell itself that has some fundamental flaws because it executes code inside environment variables that are totally unchecked. You could have a brilliant programming language and still make the exact same mistake.
While you may say that is "by design" it is not common for Bourne shell to do so and most of shell scripts are written to be Bourne shell compatible. By choosing to allow this to happen, Bash programmers made a giant hole in shell security.
I was promised a flying car. Where is my flying car?
The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.
You are correct that this is not a remote exploit by itself. Only with CGI does it become remote. It is a code injection vulnerability that when used with CGI becomes a remotely exploitable vulnerability.
This is not a "blanded" attack that combines with a CGI vulnerability. There is no vulnerability in CGI; it works as specified (you could say that there is a design vulnerability in CGI - and I would agree about that).
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I think you'll find bone-headed obvious holes from time to time from almost all software vendors, with MS being no exception.
This is my signature. There are many like it, but this one is mine.
Except that Windows probably has just as many holes only you dont know about them because they aren't public or because Microsoft has decided not to invest the engineering resources to fix them or because Microsoft has fixed them in a patch but the actual security flaw is still unknown publicly.
At least with Linux, if a security hole is found (and made public or released to experts in the security community or to the relavent developers or whatever), the number of people who are able to investigate and fix the hole (and make official or unofficial fixes available) is (in most cases) significantly larger than the number of people who would e able to deal with issues in Microsoft code. And the Linux guys can have patches out much faster (and they can get into distros fairly fast too)
Those of us who've been using Unix, BSD/Solaris, and Linux for the past few decades never had delusional thoughts of vaunted security of these systems in the first place.
Any system will have security issues, as most software is flawed - and systems tend to comprise of dozens if not hundreds of software components.
This is ignoring hardware errors (most people security conscious have been dealing with hardware erratas for decades too), because more often than not those hardware issues are far easier to exploit than software ones (from a time-to-discover exploit perspective).
Anyone stupid enough to re-evaluate using linux because they've only JUST realised they have to consider security, are going to be just as incompetent at running a system no matter what kernel/OS they migrate to. Good luck to 'em.
Still waiting for examples of how to exploit this (remotely or otherwise), without using an existing hole to do so.
The most repeated example is letting the web server call a shell script. Yeah, we did that 15 years ago, and WE KNEW it was a stupid thing to do. There are so many ways of script injection, and nobody gets their quotes perfectly right. I thought security had become better in 15 years, but if that example is the best they have, apparently nothing has changed.
Seriously, if that example matters to anyone but a few morons, I'd have to agree with the astroturfers. Microsoft did improve their security between Windows 95 and 7. It's still not perfect, but at least they aren't running bloody shell scripts from CGI.
The rest of the examples are passing unchecked user input to the shell, either from PHP or even the DHCP client. That's security 101 fail.
Sudo has cleared environment variables for at least a decade. Because passing unchecked user input across the user/root barrier is a security hole. The ability to run setuid shell scripts were removed from major *nix kernels around the same time, for the same reasons. So, if both sudo and kernel developers realized a decade ago that passing unchecked environment variables across the user/root barrier was a security problem, how could anyone think that doing the same thing between the unauthenticated user and a shell script through the web server would be any better.
You need to trust unauthenticated people even less that sudo users. At least with sudo users you know exactly who to hit with a clue-by-four.
You thought you could run a totally free hobbyist OS and have it be as secure as one done by paid professionals?
Be glad its there for you to use at all. People donate their time and energy to it. Don't look a gift horse in the mouth.
Some would argue that Mac OS X isn't a totally free hobbyist OS and yet, with all of their paid professionals, they have yet to patch the bug. On the other hand, Linux being a free hobbyist OS means that researchers have the ability to scan the code and discover these types of holes. Something that is impossible for closed systems.
Fucking Linux. NEVER AGAIN. At least with mswin, my stations will auto-update. (Not to mention they never would have had such a bone-headed obvious hole to start with.) Christ, even my headless server stations that I never thought I'd have to fuck with again are vulnerable. Goddmammit. This could even compromise accounts I have on remote servers if they are not keeping up-to-the-minute updates. I guess you get what you pay for. Caveat Emptor. I just never thought it would come back to bite me so hard. I suppose you never do.
What makes you think Windows doesn't have problems like this? The difference is that being open source third parties can review the code and find problems. There is no way to keep them secret and from the public. Also, fixes were pushed out within hours of notification.
Look at it this way. BASH has had this problem evidently for years and there haven't been any exploits. It was discovered by researchers analyzing the code. In an MSoft world, where nobody has access to the code but MSoft, the public finds out about security holes after they have been exploited. So I agree, Caveat Emptor.
And it's the developers of all those packages and distros that symlink /bin/sh to bash instead of something minimal and well-audited that we should be screaming at. But "remote root exploit in bash" is sexier (after all, Apple doesn't put procmail on every Mac) so that's what goes in the headline.
...and next time someone goes on a rant about systemd versus "the Unix way", remember that daemons passing input from the network to /bin/sh is part of "the Unix way".
0 1 - just my two bits