3 ms·

That the users created for Apache, database daemons, etc, default to bash for cgi.

by muyuu 12y ago

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.

That the users created for Apache, database daemons, etc, default to bash for cgi.

by muyuu 12y ago

That the users created for Apache, database daemons, etc, default to bash for cgi.

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.