Yesterday, I commented on how hardening host.conf file provides very little security. Today, I want to focus on another item often found on “server hardening” checklists: TMP directory hardening. While TMP directory hardening still has its place, I feel it has lost its effectiveness in today’s threat landscape.

Before TMP Directory Hardening
After applying these changes to your /etc/fstab file, you will end up with something like this:

/dev/sda2   /tmp                    ext3  defaults 1 1

After TMP Directory Hardening

/dev/sda2   /tmp                    ext3  rw,nodev,nosuid,noexec 1 1

What’s being done?
TMP directory hardening involves restricting activities on the /tmp and /var/tmp directories by use of mount options. The motivation for this on web hosting servers is to prevent attackers from executing code within the /tmp directory. Since /tmp is world writable, if an attack can gains access to the system, they can store and execute files from within /tmp.

For filesystem hardening, the CIS benchmarks focus on three key restrictions:

nodev – prevent devices from being created on the filesystem
nosuid – ignores the suid bit on the filesystem
noexec – do not execute files on this filesystem

These restrictions should be used of various directories, such as /tmp, to restrict activity on the server. It is also recommend that you symlink /var/tmp to /tmp to prevent hardlinks from within /tmp to data contained in /var.

cPanel has a script called securetmp that can be ran on boot to secure the tmp directory (but it does not apply a nodev restriction).

Analysis of TMP Hardening

While I still recommend this step when hardening a server, I think the usefulness of it has been lost. Attackers used to dump files into /tmp via a web application exploit. They would then try to execute these files. Switching to using noexec on /tmp directories prevented this type of attack.

Unfortunately, there is an easy way around these restrictions. You can simple call your scripts via a perl, php or similar program instead of putting an executable in /tmp.

For example, if you put a script into /tmp and try to run it directly with the noexec option enabled, the script will fail. However, if you simply run it as perl /tmp/ it will work.

More recently, most web application exploits have involved XSS exploits which directly runs code from within the script. As a result, the /tmp hardening procedures do little to protect you from these attacks.

While I still recommend doing /tmp hardening, I place little value in it. I’ve seen numerous incidents where /tmp was secured but attackers still ran code from the directory through various wrapper approaches. I’ve also seen situations where /tmp was hardened but /var/tmp and /dev/shm left open. The latter two directories are popular targets as well.

So while this step certainly does not hurt, I find it does little to improve security on a web hosting sever. I often find it listed in the laundry list of items included in server hardening checklists.

Currently, I recommend securing /tmp only when your server already has a dedicated /tmp partition. Given the low value of this technique in today’s threat landscape, I do not feel it necessary to use workaround approaches, such as cPanel’s securetmp script, to get /tmp hardened.

add_action('init', 'use_jquery_from_google');