Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

241–250 of 296 posts

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

#241
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, it's straightforward to turn it off in Apache.

Put a "#" in front of

LoadModule cgi_module modules/mod_cgi.so

in /etc/httpd/conf/httpd.conf. This prevents the code that runs CGI scripts from even being loaded with Apache, and will totally disable all CGI scripts. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.

This will break CPanel, but not non-CGI admin tools such as Webmin. I can't say anything about PHP; we don't use it.

People are out there probing. This is from an Apache server log today from a dedicated server I run.

89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

The source is on "i3d.net", which is a hosting service in Rotterdam NL. So someone is running probes from something bigger than a desktop. I sent their support people a note.

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

#242

Is there a way of preventing functions from being imported from the environment, but still allowing some variables in? My experiments with #!/usr/bin/env -i sh and #!/usr/bin/env - sh ...have not obtained what I'm after. The problem being that functions take precedence over names in the file system, so bash-4.2$ env '/bin/cp=() { echo oops;}' /bin/sh -c '/bin/cp /tmp/foo /tmp/bar' oops

If an attacker can fully control the name of an injected environment variable, then you've lost already. The attacker can override LD_PRELOAD, which is an environment variable honored by the Linux kernel itself.

LD_PRELOAD is not honored for setuid executables, but you're right, we don't want to go there.

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

#243
post #80

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?

There's nothing wrong with putting arbitrary data inside an environment variable that other programs don't assign meaning to.

The issue is that bash takes it upon itself to parse all environment variables for functions, and accidentally executes some of them.

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

#244
post #214

Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate. Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability. Status: Testing underway. Initial appraisals are that public-facing systems are likely not subject to shellshock. NO…

Android and iOS are variants of Linus What kind of variants? Doppelgänger? Clones? SCNR

Oops. Now that's funny. I had to reread several times to grok your comment. Now that I do, I am having a good laugh. I'll edit the post shortly.

EDIT: Or not - the edit button has gone. Ah well.

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

#245

When comparing security warning from RedHat https://access.redhat.com/solutions/1207723 vs Ubuntu http://www.ubuntu.com/usn/usn-2362-1/ the RedHat one wants you to run /sbin/ldconfig or reboot your machine. Why Ubuntu does not recommend this? They do ldconfig automatically?

The vulnerability only exists during the startup of a bash process. Updating bash is enough. Bash processes that are already running are past the point where they could be exploited. Future calls to bash will get the updated version. No services need to be restarted to apply the fix.

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

#246

Earlier quoted context omitted.

Yeah I get that - but surely just _calling_ /bin/bash isn't enough - you have to be able to pass in the arguments to bash that enable this exploit. And if you're not allowing user input into your system call, I still think this is a non issue in this scenario.

If php is being run from mod_cgi, then it is exploitable. The full chain of the attack: Request sent to the url, containing headers with '() { :;}; codehere' Per CGI standard: environment variables are set with the attack code. PHP is executed directly, with the environment containing the attack. PHP calls system - the same environment is there, meaning the code is executed if /bin/sh points to bash. N.B. - If /bin/s…

Correct - if you are using PHP as a CGI. This does not affect mod_php.

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

#248

Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate. Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability. Status: Testing underway. Initial appraisals are that public-facing systems are likely not subject to shellshock. NO…

iOS systems are not vulnerable unless jailbroken. There are no shells, let alone bash, present in the iOS system.

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

#249

I'm confused by this vuln report and all the attention. If I don't run any CGI thing and I don't expose SSH without pubkey and only to trusted users, what is there for me to worry about?

The CGI and SSH attack vectors are getting a lot of attention because they are so trivially exploitable. But as someone (I believe tptacek) put it in another thread, this bug has one of the biggest potential attack surfaces in history. Anything that sets any environment variable to an untrusted value and then invokes bash is vulnerable. For example, on some systems, simply connecting to an attacker-controlled network…

Alright so necessary conditions are "sets env variables" + "invoke bash". That clarifies, thanks.

I'm not advocating not updating, I'm just trying to understand what to do with this info for say, my hosted project that _doesn't set env vars nor invoke bash_.

Post reply on HN