cPanel 11.23.1-EDGE_24773 - cPanel daemons insecure $PATH



DESCRIPTION


When a local user "su"s to root, part of their $PATH will contain /home/username/. When you use "su -", this will not occur. The problem is that when a local user just ran "su", then ran /scripts/upcp, cpsrvd would inherit the insecure $PATH, instead of cleaning the environment first.


[root@host ~]# gdb -p `cat /var/run/cpsrvd.pid`
(gdb) x/s 0x8918038
0x8918038: "PATH=/usr/local/jdk/bin:/usr/local/jdk/bin:/usr/kerberos/bin:/usr/lib/courier-imap/bin:/usr/local/bin:
/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/X11R6/bin:/home/username/bin:/usr/local/bin:/usr/X11R"... 

Note the "/home/username/bin" in the output above.


The following commands did not result in an insecure $PATH:

service cpanel start
service cpanel restart


The following commands did result in an insecure $PATH:

/scripts/upcp ( which calls /usr/local/cpanel/etc/init/startcpsrvd )
/usr/local/cpanel/cpsrvd restart
/usr/local/cpanel/cpsrvd-ssl restart 



IMPACT


As far as I can tell, this would have required several unlikely things to occur in order to be taken advantage of. First, someone malicious (who does not know the root password) would need access to the "username" account. Second, cpsrvd would need to attempt to execute a command that does not exist in any part of the $PATH preceding the "/home/username/bin" entry (either because the binary does not exist on the system in those paths, or because the command was misspelled somewhere in cpsrvd). If the malicious user wrote an executable file to /home/username/bin that would be executed by cpsrvd, root access could have been possible since the file would be executed by cpsrvd, which runs as root.