Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

111–120 of 296 posts

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

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

Considering most exploits are found via fuzzing tools, I think your assumption is pretty far away from reality. If people could casually look at code and see vulnerabilities, then we wouldn't have any. Also: MS Shared Source initiative

But people can casually look at code and see vulnerabilities, any time they want.

Although your point about the methods of exploits changing the dynamic is valid.

>Also: MS Shared Source initiative

Fair point.

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

#112
post #90

Earlier quoted context omitted.

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

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.

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

#113
post #110

Earlier quoted context omitted.

Your OS vendors security list.

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.

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

#114
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.

If you run CGI you may be/probably are.

Honestly, I'm having trouble seeing how this is the end of the world vulnerability that it's being hyped as.

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

#117
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.

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

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

#118
post #111

Earlier quoted context omitted.

Considering most exploits are found via fuzzing tools, I think your assumption is pretty far away from reality. If people could casually look at code and see vulnerabilities, then we wouldn't have any. Also: MS Shared Source initiative

But people can casually look at code and see vulnerabilities, any time they want. Although your point about the methods of exploits changing the dynamic is valid. >Also: MS Shared Source initiative Fair point.

>But people can casually look at code and see vulnerabilities, any time they want.

I think you're dismissing the level of experience, smarts, and inter-disciplinary knowledge it takes to find a bug like this. More than likely, even those with all those skills and at the 1% of them can't just eyeball code and go, "Ah yes, here." They're instead writing a lot of little tools and seeing what they can break. Then they go back, see what broke, and work out if its possible to exploit that exception or crash condition.

These types of tools and methods work just as well with closed source. Attacking closed source seems very unfair to me in these scenarios.

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

#119
post #26

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

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

Do two hugely impactful nix-centric security bugs overshadow the hundreds of minor ones found in Microsoft products?

Yes, certainly.

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

#120
post #111

Earlier quoted context omitted.

Considering most exploits are found via fuzzing tools, I think your assumption is pretty far away from reality. If people could casually look at code and see vulnerabilities, then we wouldn't have any. Also: MS Shared Source initiative

But people can casually look at code and see vulnerabilities, any time they want. Although your point about the methods of exploits changing the dynamic is valid. >Also: MS Shared Source initiative Fair point.

>But people can casually look at code and see vulnerabilities, any time they want.

They could, but they don't. Same way I can look at the sky and see an asteroid. Possible? Sure. Likely? Not without some pretty advanced tools or a hell of a lot of luck.

Post reply on HN