Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

Post reply on HN
Print view View original

101–110 of 296 posts

Re: Everything you need to know about the Shellshock Bash bug

#101

Post by huhtenberg »

jamroom wrote: post #16
nodata wrote: post #13

Earlier quoted context omitted.

Erm what about mod_php etc?

from my understanding mod_php is not affected. However, if you have any system() calls in your PHP code AND you allow user input to be used in those system calls, then /bin/bash could be executed via the system call. If you control what is running in your system call - i.e. system("echo 'hello world'"); then I believe you are OK. But that's "security 101" and you should never be opening a system call to user input.

> AND you allow user input to be used in those system calls

This is not required for exploiting the vulnerability at hand.

Re: Everything you need to know about the Shellshock Bash bug

#102

Post by mrfusion »

mrfusion wrote: post #81

So if your server is set up with limited permissions for the apache-user, are you still at risk? I don't think the apache-user if properly restricted can write to directories, or even read most of the system files?

Isn't it kind of a security best practice to assume your web user can be compromised and plan accordingly with permissions?

Re: Everything you need to know about the Shellshock Bash bug

#103

Post by muyuu »

Either of these will typically show you your running terminal:

ps -p $$

echo $0 (command name that was used to invoke the shell)

Not reliable: echo $SHELL (preferred shell for the user, not necessarily what is running)

Also note that you may want to remove/fix bash to make sure it doesn't get run by something else. A CGI script may run it despite you changing your default shell to something else.

Re: Everything you need to know about the Shellshock Bash bug

#104

Post by jcarreiro »

diydsp wrote: post #80
mrfusion wrote: post #75

I see how Apache passes request information through environment variables but I don't see how bash comes into play in typical CGI. Is anyone up for educating me? I see http request -> apache -> env variables -> php What am I missing?

I think I have the same question.. why is this called a "bash" bug? Is it not a webserver bug? Why does the webserver send data to bash through environment variables? Is there no better way to do it?

It's a bash bug because the bug is ultimately in how bash parses environment variables. My understanding is quite limited, but IIUC, after the invalid function definition, the bash parser simply stops trying to parse the environment, and the remaining input tokens get used as arguments to the next command executed by the shell.

Re: Everything you need to know about the Shellshock Bash bug

#105

Post by Timothee »

mrfusion wrote: post #81

So if your server is set up with limited permissions for the apache-user, are you still at risk? I don't think the apache-user if properly restricted can write to directories, or even read most of the system files?

From the article, it sounds like the issue is not just with Apache but also ssh, DHCP and others. So I'd just assume you're still at risk regardless of your Apache user configuration. (in any case, it's safer to act as if)

Re: Everything you need to know about the Shellshock Bash bug

#106

Post by mbi »

justincormack wrote: post #66
wodow wrote: post #60

Is there a (low volume) mailing list that would have alerted me to both this and Heartbleed?

Your OS vendors security list.

For Debian that would be debian-security-announce [1], I try to read every post from that list.

1: https://lists.debian.org/debian-security-announce/

Re: Everything you need to know about the Shellshock Bash bug

#107

Post by sneak »

mrfusion wrote: post #81

So if your server is set up with limited permissions for the apache-user, are you still at risk? I don't think the apache-user if properly restricted can write to directories, or even read most of the system files?

It can read your application source code, read your database credentials, access your database, and exfiltrate its contents. Yes, you are at risk.

Re: Everything you need to know about the Shellshock Bash bug

#108

Post by acdha »

mrfusion wrote: post #81

So if your server is set up with limited permissions for the apache-user, are you still at risk? I don't think the apache-user if properly restricted can write to directories, or even read most of the system files?

Things like that lower the risk: run everything as a low-privilege account (better, not even www-data but per-site), chroot()-ed, etc. and certain classes of attack will either fail or at least be easier to clean up.

The problem with all of this is that it assumes that you don't have privilege escalation vulnerabilities on the local system, which is often not the case unless non-trivial effort has gone into hardening the server – e.g. all of that privilege separation is a waste if someone sledgehammer-ed a chmod 777 into a script rather than setting the appropriate ownership and permissions or someone delayed a kernel update because they didn't want the downtime and “knew” that only trusted code ran on that system.

Re: Everything you need to know about the Shellshock Bash bug

#109

Post by txutxu »

With only static content (all logic implemented via cron).

    $ grep nginx /etc/passwd

    nginx:x:105:111:nginx user,,,:/nonexistent:/bin/false
And the only other service listening in this machine is SSH, but it's limited by iptables only to my home IP.

I think I'm safe. Now installing updates patches bash.

Anyway, I've seen that syntax before (I'm talking of years here), on #bash in freenode.

Simply nobody did apply this from a security view point in the channel...

Re: Everything you need to know about the Shellshock Bash bug

#110

Post by wodow »

justincormack wrote: post #66
wodow wrote: post #60

Is there a (low volume) mailing list that would have alerted me to both this and Heartbleed?

Your OS vendors security list.

Well, I mostly use Debian and Arch:

Debian isn't low volume: https://lists.debian.org/debian-security-announce/2014/threa...

Arch isn't high volume enough(!) https://mailman.archlinux.org/pipermail/arch-security/

Arch recommends the oss-security list, which is all too high volume http://www.openwall.com/lists/oss-security/2014/09/

Post reply on HN