3 ms·

FYI some routers, STBs run httpd with cgi-bin. It's lot worse than some PHP vulnerability, because PHP is not used on those devices but bash is.

by dz0ny 12y ago

yourad_io 12y ago
Don't most routers run some form of busybox or ash rather than bash?
- mzs 12y ago
  Yes, I'm getting really annoyed seeing comments like this pop-up repeatedly, ash has no exporting of functions even: # type foo foo is a shell function # export -f foo -sh: export: Illegal option -f
mhurron 12y ago
You know, this whole thing would be a lot clearer to everyone if the following would be clearly communicated: Are you running sshd with ForceCommand? - Get Patching (when a patch is out) Are you running a webserver that uses 'old style' CGI (are you really sure you're not?) - Get Patching (when a patch is out) Are you absolutely sure neither of the above is true? Then patch bash in your next patch cycle. The super-hype vulnerabilities are getting is just muddying the waters when trying to get actual information.
- nitrogen 12y ago
  Are you certain that no process on your system ever sets an environment variable to a user-controlled value? Get patching. Hypothetical: some GPG library is just a wrapper around /usr/bin/gpg. Maybe that library uses an environment variable to set a password that doesn't show up in ps. Maybe that library used system() instead of execve(). That password is now an attack vector. See also /usr/bin/mail called by mail() functions in scripting languages, /bin/hostname, /bin/uname, etc. If any user-controlled variable is set in the environment, those calls become potential attack vectors
  - mhurron 12y ago
    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.
    - pyre 12y ago
      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.
    - sophacles 12y ago
      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)
    - nitrogen 12y ago
      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 https://news.ycombinator.com/item?id=8368861).
- ZoFreX 12y ago
  I think the "super-hype" is warranted. You've missed out a large number of possible ways this could be exploited, so the above advice would leave a lot of people vulnerable. Furthermore, because it's such a common thing to pass environment variables and to invoke bash, people expect far more attack vectors to be discovered as this unfolds. In addition the current patches rely on huge swathes of bash code being bug-free, we've already seen one patch circumvented and with so many eyes suddenly on code that wasn't closely inspected from a security angle for over two decades, I would bet on seeing far more things being found over the next weeks or months.

FYI some routers, STBs run httpd with cgi-bin. It's lot worse than some PHP vulnerability, because PHP is not used on those devices but bash is.

by dz0ny 12y ago

FYI some routers, STBs run httpd with cgi-bin. It's lot worse than some PHP vulnerability, because PHP is not used on those devices but bash is.

yourad_io 12y ago

Don't most routers run some form of busybox or ash rather than bash?

mzs 12y ago
Yes, I'm getting really annoyed seeing comments like this pop-up repeatedly, ash has no exporting of functions even: # type foo foo is a shell function # export -f foo -sh: export: Illegal option -f

mhurron 12y ago

You know, this whole thing would be a lot clearer to everyone if the following would be clearly communicated: Are you running sshd with ForceCommand? - Get Patching (when a patch is out) Are you running a webserver that uses 'old style' CGI (are you really sure you're not?) - Get Patching (when a patch is out) Are you absolutely sure neither of the above is true? Then patch bash in your next patch cycle. The super-hype vulnerabilities are getting is just muddying the waters when trying to get actual information.

nitrogen 12y ago
Are you certain that no process on your system ever sets an environment variable to a user-controlled value? Get patching. Hypothetical: some GPG library is just a wrapper around /usr/bin/gpg. Maybe that library uses an environment variable to set a password that doesn't show up in ps. Maybe that library used system() instead of execve(). That password is now an attack vector. See also /usr/bin/mail called by mail() functions in scripting languages, /bin/hostname, /bin/uname, etc. If any user-controlled variable is set in the environment, those calls become potential attack vectors
- mhurron 12y ago
  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.
  - pyre 12y ago
    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.
  - sophacles 12y ago
    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)
  - nitrogen 12y ago
    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 https://news.ycombinator.com/item?id=8368861).
ZoFreX 12y ago
I think the "super-hype" is warranted. You've missed out a large number of possible ways this could be exploited, so the above advice would leave a lot of people vulnerable. Furthermore, because it's such a common thing to pass environment variables and to invoke bash, people expect far more attack vectors to be discovered as this unfolds. In addition the current patches rely on huge swathes of bash code being bug-free, we've already seen one patch circumvented and with so many eyes suddenly on code that wasn't closely inspected from a security angle for over two decades, I would bet on seeing far more things being found over the next weeks or months.