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!
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.
wait, what? Bash is a "programming language"?
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*
Yes - it might well be the most popular programming language on Linux, and much of what you see when your system is starting up for example is written in bash.
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.
Compared to DOS Shell.
Bash is a "programming language"?
Yep! All those files where you see #!/bin/bash at the start, those are written in it.
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?
DOS Shell (the "windows-y" "GUI-y" thing that came with DOS 5)?
Or batch files? :)
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)
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.
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.
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.
The vulnerability is in the language parser, not the language design by itself. Imagine that in java (or whatever is a "proper" designed language for you, just that don't be PHP) you put some weird syntax that makes the compiler to execute injected code.
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.
The complexity of the language syntax drives the complexity of the language parser.
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!
Unix security model with almighty root is horribly broken. You have to use band-aids like SE with that. Windows does not use such a mathematically unsound design from the seventies.
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.
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'?
The design of the language (which is fine by the way, its different, but its fine), has absolutely nothing to do with these bugs.
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.
Innocent until proven guilty. All I see is that the Microsoft vulnerabilities are no more in the headlines.
You could as well say that Heartbleed and Shellshock are just scraping the surface, and are an indicator that open source might have more dragons lurking.
[Citation Needed]
Oh you have none, you're just a shill.
# 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?
Depends on the headlines you read.
http://web.nvd.nist.gov/view/v...
If you get your server administration advice from CNN's front page, perhaps your employer is not getting his/her money's worth.
Kythe
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)
Nope.
A lot of it is written in Bourne shell scripts, which may be interpreted by bash, ksh, dash or some other "sh" implementation.
Some of it (too much) is actually written in bash, but probably shouldn't be. (Hello authors of "zless"),
Watch this Heartland Institute video
...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
An unprovable assertion.
Gamingmuseum.com: Give your 3D accelerator a rest.
Hackers can use OpenSORES to find vulnerabilities to exploit & abuse faster (for bad purposes of theirs).
How the fuck did Windows get into this?!?
Your friend: "I'm having a problem with my girlfriend, and wondering if I ought to dump her and get a new girlfriend."
You: "I think you'll find that snuggling with rabid baboons isn't all it's cracked up to be."
Your friend: "WTF? I wasn't suggesting forsaking human companionship, just this one particular girl."
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?
Oh it parses it just fine. It was just a dumb idea to parse it in the first place.
Re-read the latest CVEs. There are bugs in the parsers that can be exploited, so even if you're never invoking the functions they're already run through the parser and the parser is breaking things for you.
I am TheRaven on Soylent News
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?
On a Fedora / Red Hat / CentOS / ScientificLinux box, do:
yum install rpmdevtools
cd
file * | awk '($2 = "POSIX")' | cut -d: -f1 | xargs checkbashisms
Yeah, "too much" is an understatement.
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.
file * | awk '($2 = "POSIX")' | cut -d: -f1 | xargs checkbashisms
Lesson to self: Test before posting. That should be == instead of =, of course:
file * | awk '($2 == "POSIX")' | cut -d: -f1 | xargs checkbashisms
Sorry about that.
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
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)
There is a flip side to that, which is that too many cooks with no common management may royally spoil the broth, which is what has happened.
When found, this was embargoed and should have been fixed under embargo, properly. Instead, someone pushed out half-baked patches that were proved to be still vulnerable within hours (if not minutes), and by then everything was public. So now we have everyone and his dog patching in panic mode, three, four or more(?) sets of patches now, with each one still proving vulnerable, because collectively we blew our chance to fix it (and test it) properly the first time.
The eventual fix will have to be to stop playing who-finds-the-parser-bugs-first and accept that the whole feature is a security hole and needs to be removed or radically changed - something that could and should have been predicted at the start. There are various patches flying around now that do just that, probably in different incompatible ways. Those changes will, inevitably, break some stuff - and of course we could have looked and tried to figure out the extent of that, and mitigated the effect and been ready with the announcement, if it were still under embargo, but we blew that chance.
I am all for saying that the open source development model is better - but this really is not the best example to use to illustrate it, in fact it's already heading into embarrassing farce territory.
There are a LOT of organizations re-evaluating the idea of using linux on the server now...
There are lots of orgs thinking about switching to Linux? Well, yeah, thanks for that, Captain Obvious. Tell us something else we already know.
Il n'y a pas de Planet B.
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....
Batch search & replace just screams "Beta reduction of lambda calculus statements" to those who love Turing tarpits. Or perhaps Church tarpits in this case.
Not a sentence!