Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

91–100 of 296 posts

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

#91
post #12

Keep an eye on the patches directory for whatever version you use: http://ftp.gnu.org/pub/gnu/bash/ Just had to manually patch a CentOS4 legacy system. What I find interesting is the patch has been around since the 16th, what took so long and what finally lit a fire under the mainstream *nix releases?

>CentOS4 legacy system Jesus. That's been out of support for well over 2 years. I can't imagine this is the only problem it has. I'm curious: what's keeping the organization from upgrading it?

Heh, you should see some of the systems that orgs I work with still have running. Just checked on one of my favorites:

  $ uptime
   07:26:20 up 3280 days, 16:23,  2 users,  load average: 0.00, 0.00, 0.00
  $ cat /etc/issue
  Debian GNU/Linux 3.1 \n \l
This one doesn't even have the excuse of running a piece of lab equipment (I saw such a system recently running Win95 without OSR1, so it doesn't even have USB support. They move data around with ZIP disks!).

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

#93

Earlier quoted context omitted.

Thanks! EDIT after OP's edit. Sad. This situation feels kind of a disaster-relief thing; not a good time to think about monetizing it. Still, I do understand you don't want people thinking you'll always be protecting them from everything even if they don't pay. EDIT2 after clarification downthread, previous edit is to be disregarded.

It's less about trying to monetize it than about the cost to us of suddenly inspecting every request that goes through us. We service a huge volume of traffic and part of our core value is performance so keeping our processing latency is low as possible is important. (Note: I removed sentence about CloudFlare pricing from previous comment to avoid any confusion about monetization)

Would it be possible to enable it temporarily to see whether the change significantly impacts your processing latency?

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

#94

Earlier quoted context omitted.

Thanks! EDIT after OP's edit. Sad. This situation feels kind of a disaster-relief thing; not a good time to think about monetizing it. Still, I do understand you don't want people thinking you'll always be protecting them from everything even if they don't pay. EDIT2 after clarification downthread, previous edit is to be disregarded.

It's less about trying to monetize it than about the cost to us of suddenly inspecting every request that goes through us. We service a huge volume of traffic and part of our core value is performance so keeping our processing latency is low as possible is important. (Note: I removed sentence about CloudFlare pricing from previous comment to avoid any confusion about monetization)

Fair enough; that's what I meant when asking if it is feasible for you to do so.

Thank you for clarification!

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

#95
post #2

From the article: "Of course one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell" If you're on Ubuntu: a2dismod cgi service apache2 restart If you're NOT running any CGI scripts this will disable CGI support in Apache. Not sure if that takes care of things 100%, but might be helpful.

If you're on Ubuntu or Debian your CGI scripts will probably use dash, not bash.

Debian yes, Ubuntu's default is bash. So is Mint's.

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

#96

Earlier quoted context omitted.

I'm going to bring it up internally, but don't hold your breath.

Thanks! EDIT after OP's edit. Sad. This situation feels kind of a disaster-relief thing; not a good time to think about monetizing it. Still, I do understand you don't want people thinking you'll always be protecting them from everything even if they don't pay. EDIT2 after clarification downthread, previous edit is to be disregarded.

The monetization has not been put in place right now. It has always been there (the possibility to add these rules).

If this is a disaster-relief thing-y, CloudFlare should then be eligible to receive government money later. I doubt that would be even considered by any parties.

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

#97
post #4

So trying to understand the issue here, is this actually a bash thing or a problem with the web server forwarding commands to bash? I don't understand why bash would be listening to network traffic on its own.

Seriously, for an "Everything you need to know about X" post, they're very light on the details of what exactly makes a web server vulnerable.

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

#98

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?

Apache user can probably write to /tmp, and from there the attacker can construct a way into the system (bindshell, reverse shell). He can then start reading your PHP config files (db passwords) or try to use other vulnerabilities to escalate his privileges.

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

#99
post #90
post #80

Earlier quoted context omitted.

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?

If something, it's a bug in the CGI specification, since passing HTTP headers as environment variables is part of the standard.

Sort of I guess, but why does bash need to loop over all of the env variables and execute them? I don't think CGI had any reason to think that would ever happen?

(I guess that's basically what it's doing?)

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

#100
post #42
post #31

Earlier quoted context omitted.

cPanel is probably the most popular reseller hosting software for shared web hosting and it relies on CGI in all kinds of places. That alone provides a huge amount of exploitable hosts - I tried to Shodan it (port 2082) but it seems down right now. Since cPanel is designed for people without system administration experience, it's unlikely they will be patched in a timely manner too. All the CGI scripts are in known s…

cPanel uses CentOS and does system upgrades ala yum update. Dunno if that is on by default or not though. But you aren't going to get into its cgi interface without login so that would have to be cracked first.

But it seems you only need one login to compromise the whole server. If I buy $3 hosting on a shared server then I can pwn the whole server can't I (using cPanel to escalate an attack above my privelege level)? What are the chances that one user account on a shared server is crackable, pretty high I'd imagine.
Post reply on HN