Hacker News Reader

Comment by ilconsigliere | Hacker News Reader

Am I wrong in thinking that seems a bit worse than Heartbleed?

The exploit is worse.

But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing.

Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge.

But as it is... I'm not sure?

Makes sense. This just strikes me as a very flexible exploit.

You could search for *.cgi scripts indexed by Google. They may not be written IN Bash but maybe one of them opens up a shell to execute a command. Even if you are not explicitly passing any bad data to it, the environment will be passed and trigger this crazy vulnerability.

Google inurl:cgi-bin inurl:.sh

Yeah, that makes sense. Did you try it?

Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are not what we're looking for, mostly forum posts asking about how to make a bash cgi-bin. (Answer from the future: don't).

I _think_ putting quotes around the ".sh" is supported to force the result to really have the period before the sh in the url.

inurl:cgi-bin inurl:".sh"

0 hits

    inurl:cgi-bin "inurl:\.sh$"

320k results here. The slash and $ made a difference but they are not parsed as regex other chars work too. Not sure what's going on here.

okay, i was wrong, this is way way worse.

It is far worse in the sense that it can lead to remote code execution. However, the number of vulnerable sites is far far fewer. Like Heartblead this one will likely have a very long tail of systems remaining vulnerable. My guess is we will see this vulnerability used to compromise big targets in the next few months.

Reply on news.ycombinator.com