5 ms·

From the article: "Of course one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell" If

• billadoid 12y ago
  If you're on Ubuntu or Debian your CGI scripts will probably use dash, not bash.
  • ansible 12y ago
    I've just our few Apache 2 systems that are Internet facing. Some of the site configs did have the standard Ubuntu CGI stanzas in them. However, the `/usr/lib/cgi-bin` directories were empty. All this has made me a bit nervous though. I certainly didn't change the system to use bash instead of dash.
  • muyuu 12y ago
    Debian yes, Ubuntu's default is bash. So is Mint's.
    • jewel 12y ago
      On Ubuntu, /bin/sh is a symlink to dash. /bin/sh is what system() will invoke.
      • billadoid 12y ago
        init scripts will probably run from dash[1] [1] https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
      • muyuu 12y ago
        It is, however when you create a user its default shell is bash unless otherwise specified.
        • jewel 12y ago
          Of course, but what's the exploit vector in that case?
          • muyuu 12y ago
            That the users created for Apache, database daemons, etc, default to bash for cgi.
            • Zancarius 12y ago
              The passwd file contains the login shell configured for that user. Operating in the context of a daemon for most sane applications, this configuration doesn't (or shouldn't?) matter unless the user logs in. [1] For Apache, I believe /bin/sh (or the shell it points to) is what's at issue here. [2] [1] http://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell http://unix.stackexchange.com/questions/38175/difference-bet... [2] http://security.stackexchange.com/questions/68146/how-do-i-secure-apache-against-the-bash-shellshock-vulnerability http://security.stackexchange.com/questions/68146/how-do-i-s... (This is also discussed earlier in the thread.)
              • muyuu 12y ago
                Apache uses APR, which is a separate package/set of packages to the webserver proper. Depends on the distro how this works exactly. See for instance https://launchpad.net/ubuntu/precise/+source/apr-util https://launchpad.net/ubuntu/precise/+source/apr-util Unless the distro changes it, APR defines SHELL_PATH as a macro pointing to /bin/sh (note this isn't the homonym env variable, that would be a serious problem if it was since shellshock allows setting env variables by other means that are very public by now). In a system I have access to, the installation procedure for some servers (not webserver necessarily) includes creating users with a full environment to be able to issue commands for these servers at a higher privilege. At the creation of these users, Ubuntu Server assigned them bash as their shell. I wonder if they're attackable at their public ports, but I haven't bothered trying to find attacking vectors since they were in production and the sysadmin got rid of bash as soon as he could. Not giving much detail here since I assume there will be plenty of compromised servers in the wild right now, including DB servers, proxies, etc.
• nodata 12y ago
  Erm what about mod_php etc?
  • jamroom 12y ago
    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.
    • nodata 12y ago
      mod_php is just as vulnerable as running php cgi scripts.
      • jamroom 12y ago
        in what way?
        • noir_lord 12y ago
          It's really not.
      • nkozyra 12y ago
        It seems like the pathway must be exploiter -> machine -> conduit (in this case, a web server) -> bash command through scripting language but that doesn't really make sense to me. if it's in the header as a cookie header, in php that would require something like this: $someVar = $_COOKIE['somecookiekey']; exec($someVar); this is a super fringe case, and wouldn't warrant this big of a deal. for this to be a 10/10 issue, it has to mean that processing the header files in Nginx/Apache results in some buffer overflow or for those values to be directly fed to bash. otherwise the risk is super minimal, so I don't think it's a matter of making system/exec calls on user-supplied data.