Steven, what do you mean?
If you are talking about the executions, we use the internal mechanism of apache to check if a file is present and then, if it is, we chroot to its home folder and execute it.
Since we have chrooted, the Time-Of-Use is now affecting only the application it self.
If you are talking about the symlink checks, unfortunately apache does not give us any other option
Steven, unfortunately the problem is not solvable by doing file tests.
I have built a custom apache with custom apr and patched the actual open calls.
But I also made a test script that was able to hit the same race condition.
The problem is that, the symlink may not be the last part of the path, that is accessed. So if the symlink is in the middle of the path, you have to test the whole path... but while you test, the path may change.
If I check the SYMLINK and it is OK, while I'm checking dir1 and public_html the attacker can still replace the SYMLINK and no matter how many times I check the whole path, it is possible for an attacker to change it before I open it.
So the only option would be to chroot even the non-cgi requests, but I'm a bit reluctant to do that, since it costs a lot more and it is not practical in with the prefork MPM.
For this to work properly, we were considering working with the ITK MPM.
I have also looked at mod_ruid2 and its way of implementing the same. But the risks there seamed far worse then the gains.
Last edited by hackman; 11-11-2013 at 11:34 AM.
Reason: Added mod_ruid2 comment
Steven, we advertise, and I quote from our site "Minimize the risk of a single account affecting others on the server".
Regarding the symlink protection, there are patches(grsec) that fix this issue permanently, but that patch is doing check on every open. I don't know for BetterLinux, but CloudLinux is doing the same, but for every process that is running in the CageFS.
All of these solutions are in the Kernel.
Our solution is in user space, does not alter the kernel in any way, works on all kernels and adds more security then what Apache natively offers .
If we talk strictly security, even with disabled FollowSymlink a determined enough attacker can abuse the same race condition.
So our solution tries to be in the middle, give the flexibility back to the host while doing the most that can be done in user space without sacrificing precious resources.
As you are well aware, security is a balance act between flexibility, performance and security.
Sure you say that but you are missing a important piece from the same webpage:
Thus, even if there is a single account with a security flaw, the other users on the server could not be attacked through the web server or the cron services.
You say right there that they cannot be attacked, and that is false. Its false advertisement as far as I am concerned.
Litespeed has stopped this exploit in userspace a few weeks ago, and so has bluehost with their apache patch.
Even cloudlinux originally had a userspace patch before their kernel based solution that beat the hell out of your product 10 fold. SecureLinks was part of the modhostinglimits module.
Cloudlinux's current protection is similar to grsecurity's protection.
Your solution is no better than running unpatched. In no way are you minimizing any risk, as it is reproducible on demand 100% of the time with zero effort.
Yesterday we found a solution that completely fixes this problem and also removes the need to do path checks.
We are currently testing this and within a week or max two we will push it to our stable repository. Next week it will be available to all of our customers that want to test it from our testing repository.
I have revised the way we do chroots and Hive will be able to do exactly what is written on the web page.
Again, thank you very much for sparking this discussion.