4 ms·

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

• jtdowney 12y ago
  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.
• jrochkind1 12y ago
  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?
  • ilconsigliere 12y ago
    Makes sense. This just strikes me as a very flexible exploit.
  • Erwin 12y ago
    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.
  • apawloski 12y ago
    Google inurl:cgi-bin inurl:.sh
    • jrochkind1 12y ago
      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
      • nisa 12y ago
        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.
  • jrochkind1 12y ago
    okay, i was wrong, this is way way worse.