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

141–150 of 296 posts

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

#141

Post by ChuckMcM »

jgrahamc wrote: post #61
TeMPOraL wrote: post #59

Earlier quoted context omitted.

Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)? It could do a lot of good for people and be a great PR move at the same time.

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

Consider that the bug can be used as an amplification attack and you have a lot of webservers behind the free plan. I'm guessing you don't want to have Cloudflare's infrastructure be the IPs that everyone is blocking because some yoyo is using this to turn those machines into DDOS slaves. Might help your case internally.

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

#142

Post by theGimp »

hderms wrote: post #132
nacnud wrote: post #130

Unless I've missed something, could some benevolent person use the bug to cause remote systems to run something like "sudo apt-get update && sudo apt-get install bash", to patch the vulnerability automatically? (it makes lots of assumptions, but surely it's better to have some patched systems as a result.)

sudo requires a password to be entered by default, right? I would guess that for most setups this wouldn't be possible without some kind of privilege escalation as well (or if the webserver was running with root privileges).

You'd be surprised by the number of servers that don't ask for password when you try to use sudo. They just assume that the actual owner issued the command and go straight to issuing the command as root.

(Caveat: typically it has to be a certain user)

I'm ashamed to admit I used to think that was convenient. It makes systems infinitely more vulnerable in the event of an RCE bug.

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

#143

Post by jfb »

zorpner wrote: post #91
embolalia wrote: post #17

Earlier quoted context omitted.

>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…

Attached via the 25-pin parallel port, no doubt?

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

#144

Post by bodyfour »

muyuu wrote: post #88
danso wrote: post #21

In another thread, I saw that this was an easy check to see if your bash was affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" If you get "busted" back, then you're affected...which is what I get with Mac OS X 10.9...however, when I try it on an Ubuntu server (14.x) that hasn't been patched in awhile...I don't get the error...Er, why is that? I thought this pretty much affected every bash since 25 year…

AFAIK bash is the default terminal shell in all Ubuntus. So yeah, you're affected.

The attack isn't against terminal shells. The biggest risk is against things that use the shell implicitly like system()/popen()/etc and they all use /bin/sh

It's certainly possible to be at risk if, for instance, you had a CGI script that was specifically written in bash (i.e. starts with "#!/bin/bash") but that's a lot less likely.

So definitely patch your Debian/Ubuntu/etc machines but do your Redhat-based ones (and other places where "/bin/sh --version" indicates that it's bash) first.

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

#145

Post by tokenizerrr »

mrfusion wrote: post #129
tokenizerrr wrote: post #112

Earlier quoted context omitted.

Bash is a shell, part of it's purpose is to deal with enviroment variables. The bug here is that the parser is getting confused, the feature being abused here is being able to declare functions as part of an enviroment variable, which is used to transfer functions to subshells in bash. Now this itself is fine, but since the parser gets confused it also executes commands after the function definition.

Thanks. So why isn't even being able to declare functions risky? could an attacker overwrite built in functions?

They could, you can try for yourself:

    git='() { echo hello; }' bash -c git
but it's generally understood that attackers should not be able to provide enviroment variable names. If the attacker can do that, they can also provide an alternative LD_PRELOAD variable.

Though IMO, yes this is risky.

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

#146

Post by idorosen »

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

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

#147

Post by jtheory »

metaphorm wrote: post #135
nacnud wrote: post #130

Unless I've missed something, could some benevolent person use the bug to cause remote systems to run something like "sudo apt-get update && sudo apt-get install bash", to patch the vulnerability automatically? (it makes lots of assumptions, but surely it's better to have some patched systems as a result.)

and how would the "benign attacker" know the super user password that sudo will ask for? its not like this is a logged in ssh session.

sudo can be set up lots of different ways -- including such that there's no password needed.

> its not like this is a logged in ssh session

That's not correct -- whatever user is executing your CGI scripts is the "logged-in" user in bash, right?

Obviously that user should be quite locked down, and should not be allowed to run sudo at all, let alone without a password... but there are so many amateur server admins out there that I imagine there are quite a few servers where this is a serious problem (with or without sudo access enabled for the executing user).

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

#148

Post by krapp »

WorldWideWayne wrote: post #123
krapp wrote: post #44

Earlier quoted context omitted.

On the one hand, if this had been in Windows, no one in the public would have been able to stumble across it, though you would expect them to be paying rooms full of engineers to make sure that's never necessary (and yet stuff happens.) On the other hand, despite the premise of open source that 'many eyes make all bugs shallow', the amount of code in the wild and the complexity of it (and the diversity of implementat…

> ...if this had been in Windows, no one in the public would have been able to stumble across it... Kind of a broad statement there, isn't it? By your logic - Where do zero day Windows vulnerabilities come from then? People outside of Microsoft have certainly reported security issues to Microsoft in the past.

I meant specifically in the source code but you're right.

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

#149

Post by jtheory »

f- wrote: post #128

Since the post is relatively non-technical, I'd like to underscore that there are substantial concerns with the original and the followup patch, because with or without it, the underlying bash code parser is still exposed to the Internet. Nobody has posted an RCE vector that would be universally bad for the patched version, but several people have already identified "hmm, that's unexpected" types of global side effec…

The idea of using bash to do anything with input coming from the internet is asking for trouble, really... It's just a flaw with how CGI works generally, and how PHP etc. encourage you to build webapps.

It's the same principle as SQL-injection attacks (and the flaw is there for the same reason! It's the obvious quick solution to just query mysql with "select * from users where username = " . PARAMS['username']....

But this is far more dangerous -- injecting malicious SQL can reveal data, or break things. Injecting malicious bash commands can reconfigure your server to do whatever they like.

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

#150

Post by gknoy »

bodyfour wrote: post #144
muyuu wrote: post #88

Earlier quoted context omitted.

AFAIK bash is the default terminal shell in all Ubuntus. So yeah, you're affected.

The attack isn't against terminal shells. The biggest risk is against things that use the shell implicitly like system()/popen()/etc and they all use /bin/sh It's certainly possible to be at risk if, for instance, you had a CGI script that was specifically written in bash (i.e. starts with "#!/bin/bash") but that's a lot less likely. So definitely patch your Debian/Ubuntu/etc machines but do your Redhat-based ones (a…

It seems arbitrarily risky to say, effectively, "My bash is vulnerable, but it's OK because it's unlikely to be called due to the defaults being Something Else" -- that might be short-term reassurance, but it sure sounds safer to fix it even if you don't think it can be exploited.
Post reply on HN