5 ms·
> Why does it need to be worse than something you might find in PHP? Because that's what it's being hyped as, or more correctly hyped as "OH MY GOD IT'S THE EN
by mhurron 12y ago
> Why does it need to be worse than something you might find in PHP?
Because that's what it's being hyped as, or more correctly hyped as "OH MY GOD IT'S THE END OF EVERYTHING" when in reality it appears that if you're not running ssh with forcecommands or a webserver with CGI enabled, you don't care, just like if you didn't run a webserver with PHP enabled a PHP vulnerability wouldn't really be much of an issue to you.
- general_failure 12y agoYeah, I am not sure why there is so much hype. From what I can tell you are affected only if you use CGI or the like somewhere in your response chain. AFAIK most people use http reverse proxies, phpfm, wsgi and the like. They are all unaffected.
- epochwolf 12y agoThere's a lot of older web applications that run via cgi.
- nitrogen 12y agoIt is not just CGI. It is any process that uses user-controlled environment variables anywhere, that later eventually happens to call something that calls something that calls system() or executes a shell script. So CUPS printer servers at universities may be vulnerable. Dhclient may be vulnerable to malicious DHCP responses. Anything that calls out may be vulnerable (lots of mail libraries actually call /usr/bin/sendmail or the like; better hope they don't use system() or a bash /bin/sh to do it). This is a big deal because there's a ton of stuff that uses environment variables that is and is not a web server, and very little time to track it all down before a black hat or oppressive regime gets there first.
- drvdevd 12y agoThink of it this way: this doesn't just affect webservers. It affects most unpatched bash instances. The vector of attack is through environment variables in bash. You could argue that 90% of the worlds' PHP servers will probably contain bash, but that the converse is not true: 100% of the worlds' bash instances may not contain PHP. Therefore, the attack surface is much larger and the attack vector much more basic to the way the OS works. Since environment variables are so "leaky" -- they are often spread between processes without any sort of checks -- there are essentially innumerable ways for an exploit to reach a vulnerable version of bash, both remotely and offline.
- mhurron 12y ago> It affects most unpatched bash instances But it needs something to expose bash to the outside world. Without mod_cgi (or the like) or sshd with a specific configuration, a vulnerable bash isn't going to be remotely exploitable.
- nitrogen 12y agoNo, it doesn't. Bash is already indirectly exposed to the world by anything that calls system() with bash as /bin/sh. More library functions than you might expect are wrappers around external binaries (e.g. mail() calling /usr/bin/mail) on PHP, Ruby, etc. Their authors probably thought they were safe with escapeshellarg()-like functions, but now any user-controlled env var set for whatever reason, not just CGI, is an attack vector, and not just through HTTP and not just through headers.
- skuhn 12y agoIt is correct that PHP's mail() function will fork a shell: sendmail = popen(sendmail_cmd, "w"); Which calls /bin/sh to execute sendmail_cmd. However, two things must also be true: 1. /bin/sh is bash 2. PHP has set environment variables with user-provided data #1 is often the case, but is much less common now than in the past. #2 is not commonly the case, PHP does not even automatically create PHP variables from user-provided data anymore (because it is a terrible idea to put untrusted data into a trusted scope without sanitizing).