Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

121–130 of 296 posts

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

#121
post #43

Earlier quoted context omitted.

Heh, yeah- those two major failures certainly overshadow the hundreds of issues Win has. :)

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.

I get BSODs all the time on Windows 8.1 because of my video card drivers.

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

#122

How about installing zsh and making that the default shell? Is that enough?

zsh is also vulnerable. (it's a bash derivative)

Can you show example code exploiting zsh? I haven't seen such, nor found such:

  » V='() { :; }; echo busted' zsh -c "echo hi"
  hi
But:

  » V='() { :; }; echo busted' bash -c "echo hi"
  busted
  hi

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

#123
post #44
post #26

I bet Microsoft are enjoying the fact that it is Linux that seems to have all the security vulnerabilities these days!

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.

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

#124
post #24
post #16

Earlier quoted context omitted.

from my understanding mod_php is not affected. However, if you have any system() calls in your PHP code AND you allow user input to be used in those system calls, then /bin/bash could be executed via the system call. If you control what is running in your system call - i.e. system("echo 'hello world'"); then I believe you are OK. But that's "security 101" and you should never be opening a system call to user input.

mod_php is just as vulnerable as running php cgi scripts.

It seems like the pathway must be

exploiter -> machine -> conduit (in this case, a web server) -> bash command through scripting language

but that doesn't really make sense to me. if it's in the header as a cookie header, in php that would require something like this:

$someVar = $_COOKIE['somecookiekey']; exec($someVar);

this is a super fringe case, and wouldn't warrant this big of a deal. for this to be a 10/10 issue, it has to mean that processing the header files in Nginx/Apache results in some buffer overflow or for those values to be directly fed to bash.

otherwise the risk is super minimal, so I don't think it's a matter of making system/exec calls on user-supplied data.

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

#125
post #43

Earlier quoted context omitted.

Heh, yeah- those two major failures certainly overshadow the hundreds of issues Win has. :)

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/

- https://access.redhat.com/security/updates/active/

- http://www.slackware.com/security/list.php?l=slackware-secur...

Anyone know where to go in order to get the Unix vulns all in one list?

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

#127
post #110

Earlier quoted context omitted.

Well, I mostly use Debian and Arch: Debian isn't low volume: https://lists.debian.org/debian-security-announce/2014/threa... Arch isn't high volume enough(!) https://mailman.archlinux.org/pipermail/arch-security/ Arch recommends the oss-security list, which is all too high volume http://www.openwall.com/lists/oss-security/2014/09/

I guess you want to filter eg the Debian list by the packages you have installed ideally. An API to the same info would be nice.

Or filter the NVD feeds from http://nvd.nist.gov/download.cfm ?

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

#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 effects when attacker-controlled strings are parsed as functions by bash. More is likely to come.

As of today, based on our conversations on oss-security, there is a third, unofficial patch that takes a much saner approach of isolating exported functions in a distinct namespace:

http://www.openwall.com/lists/oss-security/2014/09/25/13

Especially in high-value or high-risk scenarios, you may want to give it a try. And if you're interested in the reasons why the original patch is problematic, check out:

http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-b...

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

#129

Earlier quoted context omitted.

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?)

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?

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

#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.)
Post reply on HN