Mentats and Symlinks

A major element of Dune’s lore is the absence of “thinking machines” (computers), and their replacement by Mentats, who were humans that had undergone generations of artificial selection and intense training that gave them the ability perform calculations and data analysis at speeds comparable to computers. By the time the first book in the original series takes place, all computers had been long ago destroyed in some vaguely defined religious uprising, and were forbidden by the shared holy book of the Imperium’s major religions.

Thou shalt not make a machine in the likeness of a human mind.

Orange Catholic Bible

I’m starting to understand their choice.

via GIPHY

---

The end of 2021 and start of 2022 have been a busy time for Reclaim’s Infrastructure team. On top of the start of the new semester (which is always pretty busy), we’ve started work a few projects we discussed while in Nashville, and have been responding to vulnerabilities and compromises. Thankfully the compromises have been isolated and of relatively low number, but the vulnerabilities just keep coming; at least the Log4J vuln didn’t really impact us.

There is one particular compromise (or better yet, the response to it) that I and the others at Reclaim wanted to highlight. This being the compromise of some sites on the Wake Forest University Domain of One’s Own server. We worked with WFU’s IT folks to clean up the server, and they were instrumental in finding the Apache vulnerability that was probably used in the attack; that a user could create a symlink to another user’s directory and read sensitive files.

I did some work on one of our testing servers, and found that adding the following rules into the /home/.htaccess file seemed to mitigate this vulnerability; this way all user’s inherit these rules. And after some further testing, I pushed it out across all servers with Ansible.

RewriteEngine On
Options -FollowSymlinks
Options +SymLinksIfOwnerMatch

Supplementary to this fix would be to ensure those sensitive files can only be read by their owners in the first place (file permissions should be 600 rather than the default 644). Because of the breadth of applications we have available, applying a fix for all of them is just not viable, but I did figure out a rudimentary fix for WordPress (which makes up a majority of the applications we host, and a majority of the sites that were compromised). The following code placed in a file in the wp-content/mu-plugins directory will, on each WordPress core update, reset the permissions of the wp-config.php file to 600.

<?php

add_action( '_core_updated_successfully','wp_config_fixperms');

function wp_config_fixperms(){
    $wp_path = get_home_path();
    $wp_config_location = $wp_path . "wp-config.php";
    chmod($wp_config_location, 0600);
}

From my testing, it seems to do what it’s supposed to, but (as of writing this), I’m still waiting to hear back; if all is good, we will move forward with pushing it out, and may even include it as a default part of WordPress on our servers.

Sure 100% security is impossible, but we’re still working to get as close as possible, and there’s still plenty of work to be done.