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.
At least on Linux. Sorry, Mactards!
after shellshock: shell(after)shock
captcha: hilarity
Parser technology is over 30 years old. These morons can't even follow step by step directions.
Language design matters. This is why.
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.
Seems to me that there are multiple indications that the parser is quirky, ad-hoc and error-prone. Parser construction is an old discipline. Was the bash parser created by people without the proper training, and has later maintenance ignored code because it was too weird?
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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?
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?
you want to run ssh on openbsd where you'll get ksh instead of bash. yet another time when openbsd users shrug and move on...
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
There are a LOT of organizations re-evaluating the idea of using linux on the server now :(. The vaunted security has turned out to be full of swiss cheese holes.
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*
Alas, this is what comes of feature creep. There are lots of times I wish that Bash had evolved like a normal programming language rather than a simple shell with features bolted on via what were gaps in the syntax in previous versions. I miss Rexx, which is the OS/2 programming language that also serves as a secondary command shell.
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 a little unclear how I, as a user, can get exploited by this. (I know that it's bash (which pretty much makes MSWindows users immune), but what about the rest of us?)
Do I need to just browse a website on my computer?
Do I need to install Apache/PHP or some other server and open an appropriate port on my system?
Do I need to have port 22 open?
Do I need to have a root user?
Help! I'm a slashdot refugee.
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.
Open source software is often made freely available at no costs to downloaders and embedders. There is little incentive for these users to pay anything for it, including for support, since the main reason to adopt this software is to not pay at all. The result is that there are few resources for testing or documenting the software and no incentive for the developers to care about the usage by others and actively develop the software outside of their own use cases.
Further aggravating the issue is the claim by activists that the software code is reviewed by millions of people as it is freely available to anyone. The fallacy of this claim resides in the lack of interest of anyone to do this. Indeed, who would review other people's code for free or for fun? Vulnerabilities such as the Heartbleed bug are always found by using and probing the software, not by reviewing the code.
After OpenSSL and the Hearbleed bug, Bash and the Shellshock bug is the new poster child for the failed open source movement. No one cared, no one will care, other than create temporary scares. Repeat expected.
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.
Exploits galore on ANDROID (= Linux core) since it's inception so the trend you speak of's 2005 onward to prove your point. Exploits on Android have been coming out almost daily since then.
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.
Why are people still using the old, 20 (or 30 already) years old piece of crap? It's not even on par with PowerShell, yet there are already many interpreters on Unix that are quite suitable for the task: Python, Ruby, Scheme, BeanShell etc. All they need is a more convenient API to control processes.
Besides the language features, a bash replacement could also integrate or even unify the OO components such as those in GNOME and KDE. It's a lot more efficient and potentially more scalable to do things in component-level (independent from process) rather than process-level: try find|grep on 10,000 text files on SSD and you'd know what I mean; most of time is completely wasted on process spawning rather than anything useful.
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
You'd better call it the GNU/Shellshock security vulnerability!
A dhcp client passes values (like its new hostname) from the dhcp server to an environment variable before executing a shell script to setup the hostname, resolv.conf, etc.
When you are connecting to a public wifi hotspot you may get comprised because of this bug.
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?
I failed with reading sorry.
But I do want to say that passing unchecked user input to something else is not a security fail.
Interpreting user input without sanity checking is security fail.
For example Johny drop tables should be correctly put into table, because names can contain anything. You know how many Scottish people can't use their actual name because of this 'sanity checking'?
# don't work .. :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
..
.. :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"
..
env X='() {
# don't work
env X='() { (a)=>\' bash -c "echo date"; cat echo
# don't work
bash -c 'true EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF' echo "CVE-2014-7186 vulnerable, redir_stack"
# don't work
(for x in {1..200} ; do echo "for x$x in ; do
# don't work
foo='() { echo "CVE-2014-6277 vulnerable"; }' bash -c foo ref
The following O.Ses have disabled environment functions entirely, and should be safe: NetBSD, FreeBSD. This is known to break the test suites of some free software, which will be fixed eventually.
The following O.Ses. doesn't use bash for /bin/sh, system() and popen() by default and are a lot safer than the other Linux distros against exploitation of Shellshock: Debian, Ubuntu. Unless the local admin was foolhardy enough to change the /bin/sh symlink to /bin/bash because of third-party crap. Then, he is just as screwed as any user of the other Linux distros.
The following distros are known to have added the "unofficial" namespace fix in the second round of security updates, which reportedly *does* mitigate the undisclosed vulnerability: Debian, Ubuntu, Fedora, RHEL.
Since the upstream namespace fix ALSO mitigages the undisclosed vulnerability, I'd expect all distros to have picked one of the two patches by now. Note that "mitigates" means "makes it very difficult/impossible to trigger remotely", i.e. closes at least the CGI / popen / system/dhclient doors, which are the worse ones that allow for easy mass-p0wn1ng.
To know whether you have one of the two namespace fixes, which should mitigate the undisclosed vulnerability (according to Icamtuf, who discovered the two yet-to-be-disclosed security bugs):
foo='() { echo not patched; }' bash -c foo
If the command shows "not patched", you don't have the patch and you are still vulnerable to a (currently non-public) RCE, even if you applied the original one (or the subsequent upstream patch that addressed the issue found by Tavis).
Oh, and if it shows "command not found", you're good.
Damn straight! Mactards are still using a vulernable bash. Unlike us lunix geniuses that have patched bash 3 times in the past week and are still using a vulnerable bash!
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Oh it parses it just fine. It was just a dumb idea to parse it in the first place.
If somebody chokes and die eating dog shit picked up off the ground, the proper question to ask isn't "why didn't he chew before swallowing?", it's "why the fuck was he eating dog shit?"
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
what if I change default shell to zsh?
...all bugs are (supposedly) shallow. So, why did it take so long for this to be found? Do security holes not count as "bugs"?
What happens 20 years from now when you LED bulb has a network vulnerability?
Can we afford the risk of wiring our appliances to the net?
It appears to have been implemented in some ksh versions in 1988. My Bolsky/Korn ksh book says "This feature is not available on all versions of the 11/16/88 version of ksh."
GNU AWK uses the same syntax.
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.
I think it is fair to remind the geek that BASH is a product of the FSF and has been in use since 1989.
25 years ago.
Which makes a perfect farce of the notion that many eyes make all bugs shallow.
The following O.Ses. doesn't use bash for /bin/sh, system() and popen() by default and are a lot safer than the other Linux distros against exploitation of Shellshock: Debian, Ubuntu.
Unless your CGI script happens to run zgrep or any of the other things that force bash use for no obvious reason.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762915, apparently just fixed.
Watch this Heartland Institute video
Hackers can use OpenSORES to find vulnerabilities to exploit & abuse faster (for bad purposes of theirs).
Why are we still talking about this? If you are going to call BASH scripts as a CGI script or from a DHCP server just wrap BASH with a short C program that execve()'s the original BASH executable and sanitizes the environment. This is not a complicated thing to do.
I can't imagine the stupidity of these security folks or programmers. bash is not remotely, remotely exploitable. Hint, there a program that listened to a network connection, then, it decided to try and pawn off security and trustworthiness to another program. That trust was misplaces and that program is wrong.
If you accept bash commands on a network connection and feed them to bash, then you are an idiot, full stop. Now, if you validate the arguments, the format and the content of the command, for example, you allow two formats true, false. Then, reasonably you can call bash to run those two commends. What you can't do is accept any arbitrary string and pass it to bash.
Accept what you prove is trustworthy. Be willing to fix it, and claim responsibility when you are wrong.
No meta characters in environment variables, trivial, not meta characters in arguments, trivial. The argument should be a number, 0 to 255, check it _first_, then pass it.
I thought we learned this with all the sql commands from the network bugs. We seemed to do the right thing for them, why do they have it so wrong this time around?
my roomate's aunt makes $88 an hour on the laptop . She has been out of a job for 10 months but last month her payment was $21559 just working on the laptop for a few hours. learn this here now ....
http://www.wikiwages.com/
Unless your CGI script happens to run zgrep or any of the other things that force bash use for no obvious reason.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762915, apparently just fixed.
Very unlikely. Most CGI engines have built-in support for gzip compression, since it could be used for compression/decompression of the content.
Also, most "CGI" nowadays is only "CGI" by the name. Zend/PHP, RoR, mod_perl - are all either FastCGI or Apache plugins, and do not use the environment to pass information around.
All hope abandon ye who enter here.
I know I'll get flamed for saying this, but it seems to me that the Shellshock bug represents a weakness in the Unix philosophy. On Windows, if a similar issue happened with cmd.exe or PowerShell, it would have only a limited effect, because the Windows shell is basically just an administration tool, and no one in their right mind would use it to pass untrusted input of any sort. In contrast, "the Unix way" encourages piping of shell commands to other shell commands, and the use of shelling out as a substitute for proper APIs. To me as a Windows power user, the idea that a basic feature like DHCP is using a shell script behind the scenes seems crazy. The better way to write re-usable code is to do the C/C++ API first, then build both the command line and GUI tools on top of that API. "The Unix way" is a clumsy hack in comparison – and it leaves the shell as a security-critical single point of failure.
Another way to think of it is that Linux is now dealing with an issue that Windows has been struggling with for over a decade: how to fix inherently insecure design decisions without breaking compatibility with a million different legacy applications in the process. Maybe they'll need to implement the equivalent of "UAC" whenever a program tries to shell out?
If you have a NAS accessible through the Internet, it will probably soon be part of a botnet. See Using curl to test Qnap NAS for Shellshock.
And note that, as a bonus for crackers, the NAS even runs it's web server as root.
For this new vulnerabilty, there are no toy-command-checks yet I believe. But in the meantime, try the "Fun Shellshock test with curl" on the NAS boxes in your neighborhood (or anywhere else this Google search points you to).
And note that as a bonus the web server on that NAS already runs as root, so there is no need for a "privilege escalation" vulnerability. Nothing to escalate, you start from the top already.
That presupposes that the DHCP server is malicious (in which case YOU ARE ALREADY HOSED because they've already got you by the DNS) and that the client is set up to automatically execute anything DHCP provides in option 114 (who does that?).
There are no "average end users" who are vulnerable to this who aren't equally vulnerable to attacks that don't require bash at all, and work on any DHCP client regardless of operating system - you can use DHCP to supply fake DNS servers to windows and mac clients, and once you own their DNS they are hosed.
It looks like the AC has stumbled upon the truth.
Crappy programmers pawn off their data sanitation to the admins, at which point, it has become too late.
command : # strings /usr/lib/cgi-bin/php5 | grep bash /usr/local/bin/bash /usr/local/bash /usr/bin/bash /bin/bash /usr/lib/cgie-bin doing in place since forever.
gives:
Africa/Lubumbashi
#!
#!
#!
#!
what is php5 doing with those ? And no, my cgi-bin directory is not facing the world, I've had a hand-crafted
I have re-linked /bin/sh to another light-weight minimalistic shell and I use another sell as cli. Despite this, it is nearly impossible to completely remove Bash from a GNU/Linux system (Arch in my case) because several critical components depend on Bash (either simply by calling #!/bin/bash instead of sh or by depending on bash-specific functionality). Getting rid of those dependencies would give the user freedom to choose any sh-compatible shell. One reason this bash bug and the openssl bug before it are so devastating is that those two implementations are so ubiquitous. If each component in a system is easily replaceable with an alternative implementation, the impact would be far smaller.
I fear a future systemd vulnerability....