unsafe manipulation of client files allows privilege elevation
apache2_plugin.inc.php handles client files in unsafe ways in lots of places.
-
The toplevel web site directory is protected only if (optional) jailkit is used; without jailkit any of the default subdirectories (cgi-bin, ssl, tmp, web) can be replaced by symlinks, which then will be used at least as targets for chown and chmod.
-
Even with jailkit exploiting a race is possible (at least if set_folder_permissions_on_update is enabled, which is the default):
$this->_exec('chown '.$username.':'.groupname.' '.escapeshellcmd(
data['new']['document_root']));
// ... lots of operations, including a potentially very long "chown -R .../web"
if($tmp['number'] > 0 || $tmp2['number'] > 0) {
$this->_exec('chmod 755 '.escapeshellcmd($data['new']['document_root']));
$this->_exec('chown root:root '.escapeshellcmd($data['new']['document_root']));
}
-
SSL key generation may be vulnerable to symlinks in ssl/ (prevented in trunk by "chown root:root .../ssl").
-
web/stats/.htaccess, .htpasswd_stats and any .htaccess and .htpasswd files managed by the folder protection feature can be replaced by symlinks, then the symlink target will be overwritten as root (and then even chowned to the web site user, so that it could write more "appropriate" content there).
-
webdav handling has the same issues with symlinks (the webdav/ directory is owned by the web user).
-
_patchVhostWebdav() inserts filenames directly into the Apache config, but filenames may contain special characters (even including '\n').
-
Because the fastcgi starter directory is owned by the web user (unavoidable due to suexec restrictions), the starter script file might also be replaced by an evil symlink (e.g., by a PHP script with some way to bypass the open_basedir protection), then this file will be overwritten as root.
-
"chown -R" and "chmod -R" commands done on user-writable directories may be unsafe depending on the filesystem layout - they can be exploited to get access to any file on the same filesystem for which the web user has just the +x permission on the containing directory (this is enough to create a hardlink to the file, no permissions to access the file itself is needed).
Enough for now, most likely there are more bugs there...