Another ShellShock exploit in the wild

Re:Another ShellShock exploit in the wild by mhurron on Thursday September 25, 2014 @01:06PM (#8368219)

And how many of those are remotely callable? It is a local exploit without something that makes bash directly callable remotely.

That's why mod_cgi or sshd (in one configuration) make this bad, they execute whatever command passed by design. To do that with most everything else, you would need a remote exploit in that program, making the bash exploit somewhat moot in that case. Or you're not sanitizing your inputs in which case you have another problem anyway.

Bash, on it's own, is not remotely callable.

[ Parent | on HN ]

Re:Another ShellShock exploit in the wild by sophacles on Thursday September 25, 2014 @02:52PM (#8368939)

I haven't experimented yet, but I wouldn't be surprise if something seemingly innocuous like nzbget is vulnerable. It shells out to various extra processing scripts, setting a bunch of variables from the downloaded nzb file.

How about all those torrent clients? Do they safely shell out when doing transcoding stuff? I don't know - do you?

How about the absurd rube goldberg contraption that is modern email processing?

How about all of those scripts that crawl various web pages? Do they shell out anything, or set environment variables? Not just the ones you wrote, but any of the ones that are potentially being used within your organization? (it just takes one owned box in the network to gain a foothold)

[ Parent | on HN ]

Re:Another ShellShock exploit in the wild by nitrogen on Friday September 26, 2014 @12:41AM (#8371357)

Or you're not sanitizing your inputs in which case you have another problem anyway.

Sanitization is an orthogonal issue; no amount of escapeshellarg() would save someone from this issue, especially if the call to Bash is several layers of library calls and program executions removed from the developer's code (see pyre's comment: https://news.ycombinator.com/item?id=8368861).

[ Parent | on HN ]

Re:Another ShellShock exploit in the wild by pyre on Thursday September 25, 2014 @02:42PM (#8368861)

Anything that allows user-input to end up in an environment variable, that later makes any[0] call to Bash (even with the Bash command user-sanitized), will trigger this.

[0] With the caveat that it's possible to limit the inherited environment variables, but this is rarely done, and even things like $PATH could be potential vectors depending on the code.

[ Parent | on HN ]