CloudLinux vs BetterLinux Security (Default Settings)

Here is a comparison of CloudLinux vs BetterLinux with default settings to show the differences in terms of security. We have chosen to leave the default settings intact because as a lot of you know, some people simply cannot be bothered to read a manual and make the necessary changes.

For test purposes, we have created two new cPanel accounts one called “cloud” which represents CloudLinux + CageFS and the other one called “better” which represents BetterLinux + CloakFS. Both users are using a standard bash shell, not the cPanel Jailshell.

The first comparison will be how well processes are isolated from the rest of the system and other users. Let’s take a look and see how many processes each user can view.

cloud@cl [~]# ps aux | wc -l
6
cloud@cl [~]#

CloudLinux: 6 processes.

better@bl [~]# ps aux | wc -l
114
better@bl [~]#

BetterLinux: 114 processes.

Thoughts:

With CloudLinux, users are only able to see their own processes and they are not able to see any root owned processes or processes belonging to other hosting users. BetterLinux on the other hand allows the user to see every root owned process and everything else outside of other hosting users. (We have found previous exploits that were time based and CloudLinux prevented them, but BetterLinux would not in this case. There is no reason to allow users to see other processes!)

The next comparison will be to see what directories the users have access to. This test was done via SSH but the same conditions would apply for cron jobs which is another one of our favourite exploit techniques when we cannot use SSH access.

cloud@cl [~]# ls /
./ ../ bin/ dev/ etc/ home/ lib/ lib64/ opt/ proc/ sbin/ scripts@ tmp/ usr/ var/
cloud@cl [~]#

better@bl [~]# ls /
./ .autofsck base/ boot/ cgroups_cpuset/ etc/ lib/ lost+found/ mnt/ proc/ sbin/ selinux/ sys/ usr/
../ .autorelabel bin/ cgroups_blockio/ dev/ home/ lib64/ media/ opt/ root/ scripts@ srv/ tmp/ var/
better@bl [~]#

Thoughts:

With CloudLinux, users see a heavily modified file system structure that is basically a jailed environment with the bare minimum files and directories available for access. BetterLinux on the other hand allows the user to see every directory and every file. (Both prevent access to view files owned by other hosting users.)

The next comparison will be to see what files can be viewed by the users. While obviously nothing dangerous can be viewed, one ultimately wants to mitigate how much information is made available to untrusted users. The less information the better!

cloud@cl [~]# cat /etc/passwd | tail -n5
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
named:x:25:25:Named:/var/named:/sbin/nologin
dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin
mysql:x:498:499:MySQL server:/var/lib/mysql:/bin/bash
cloud:x:617:616::/home/cloud:/bin/bash
cloud@cl [~]#

better@bl [~]# cat /etc/passwd | tail -n5
hax1:x:501:502::/home/hax1:/bin/bash
hax2:x:502:503::/home/hax2:/bin/bash
hax3:x:503:504::/home/hax3:/usr/local/cpanel/bin/noshell
hax4:x:504:505::/home/hax4:/usr/local/cpanel/bin/noshell
better:x:505:506::/home/better:/bin/bash
better@bl [~]#

Thoughts:

With CloudLinux users are only able to see system users and their own account under /etc/passwd, whereas BetterLinux lists every other hosting user on the server. If you’re a malicious user and trying to gather a list of other accounts to attack or just gather information for other purposes, having the ability to list /etc/passwd would be extremely helpful.

cloud@cl [~]# cat /etc/named.conf
cat: /etc/named.conf: No such file or directory
cloud@cl [~]#

better@bl [~]# cat /etc/named.conf | wc -l
181
better@bl [~]#

Thoughts:

With CloudLinux users are not able to view the named configuration file, whereas BetterLinux allows the user to view the file in all it’s glory which would ultimately list every domain configured on the server or being used in a DNS cluster. (This is sensitive information that does not need to be viewable to the user.)

cloud@cl [~]# find /var/log -perm 644
cloud@cl [~]#

better@bl [~]# find /var/log -perm 644
/var/log/dmesg
/var/log/chkservd.log
/var/log/xferlog.offsetftpsep
/var/log/bandwidth/current
/var/log/bandwidth/version
/var/log/bandwidth/ipmap
/var/log/bandwidth/2013/Jun/27
/var/log/bandwidth/2013/Jun/28
/var/log/bandwidth/lasttime
/var/log/sa/sar27
/var/log/sa/sa28
/var/log/sa/sa27
/var/log/boot.log
/var/log/dracut.log
/var/log/cpanel-install.log
/var/log/lastlog
/var/log/xferlog.offset
/var/log/dmesg.old
better@bl [~]#

Thoughts:

With CloudLinux users cannot see any log files, whereas BetterLinux allows the user to see a handful of files which could ultimately contain information that is helpful to an attacker. Particularly the dmesg logs and last logs. (The last command doesn’t even work with CloudLinux, whereas BetterLinux will show the last users + their IP addresses that recently logged in.)

The final comparison will be the most important one. Which software will stop an attacker from exploiting a SUID binary to ultimately gain root access on the server. So many of our security vulnerabilities work with SUID binaries, so it is extremely important for us to use software that prohibits allowing a normal user to escalate their privileges.

For test purposes, the exploit file was created by us but it’s still a real world example. Just be hypothetical and replace “exploit” with “exim” which has the SUID flags set and is executable by the user. If there were ever to be an exploit in Exim, the following scenario would still apply.

cloud@cl [~]# ls -la exploit
-rwsr-xr-x 1 root root 6912 Jun 28 11:15 exploit*
cloud@cl [~]# ./exploit
cloud@cl [~]# id
uid=617(cloud) gid=616(cloud) groups=616(cloud)
cloud@cl [~]#

better@bl [~]# ls -la exploit
-rwsr-xr-x 1 root root 6912 Jun 28 11:15 exploit*
better@bl [~]# ./exploit
root@bl [~]# id
uid=0(root) gid=0(root) groups=0(root)
root@bl [~]#

Thoughts:

With CloudLinux, a user cannot elevate their privileges thus stopping the exploit dead in its tracks. BetterLinux on the other hand allowed the exploit to run which ultimately lead to a root compromise. Keeping in mind this is a default setup between the two, it is absolutely insane for BetterLinux to not have SUID protection enabled by default.