EasyApache4 symlink race protection
-
Hello :) Filesystem solutions are still the best choices: Symlink Race Condition Protection - EasyApache - cPanel Documentation: Thank you. 0 -
But the documentation leads me to believe that neither of those filesystem choices are available to me. modSecurity = no mod_ruid2, and I'm not on on CloudLinux. 0 -
Beyond a filesystem solution, a kernel secured against these types of attacks is a good option. Here are some links that should point you in the right direction: Grsecurity/Configuring and Installing grsecurity - Wikibooks, open books for an open world Grsecurity Thank you. 0 -
Thanks. That post about Hardening CentOS is very outdated (2010), for starters the patch file will 404. And if you're on a Virtuozzo Container you're more likely to need to go this route, if you can. 0 -
My VPS provider has advised me that the only solution seems to be to revert to EA3. Any thoughts on that? 0 -
My VPS provider has advised me that the only solution seems to be to revert to EA3. Any thoughts on that?
Hello :) This question was recently answered on our Edge-Users mailing list. To summarize, there are no plans to include the symlink protection patch in EasyApache 4. The recommended solution for CentOS 5 and CentOS 6 systems is to use custom symlink protection patch from the GRSecurity kernel: Index of /cpanel-images Note these kernels are not updated, however the patch is provided separately so you can apply it to your own kernel. EX:0 -
It seems that in consideration of the above and with the added items contained in Ticket #7504531 that I have had to revert to EA3. 0 -
This is really sad and depressing to hear. Tons of people rely on the symlink race condition protection patch in EA3, and telling them to use a custom kernel isn't a good answer at all. If RUID2 didn't conflict with ModSecurity, then RUID2 would be OK. Creating a conflict over a single feature of modsec (collection data) IMO is basically the old "throwing the baby out with the bathwater" There needs to be a good way to prevent cross-account symlinks on EA4 while retaining modsecurity, or it will cause serious problems for many hosting providers. 0 -
Hello, This question was recently brought up again internally. The decision to exclude these patches in EasyApache 4 relates to their effectiveness against symlink attacks. The patches offered in EasyApache 3 are considered workarounds, as opposed to full blown protection solutions. They prevent the TOCTOU race condition, but kernel level protection is not offered. The following is a list of the preferred solutions: Cloudlinux SecureLinks Cloudlinux CageFS Grsecurity Kernel Symlink Protection LitespeedTech Mod_Ruid2 Note that internal case EA-4430 will allow for the combined use of Mod_Security and Mod_Ruid2 / mod_mpm_itk, despite the minor bugs currently associated with using them together. Thank you. 0 -
Perhaps I am late the party on this one. But as you've said a file-system based solution is best. So wouldn't the best solution be to educate users so that they understand file permissions? PHP files are run as the VirtualHost user, at least with suPHP and PHP-FPM, so why should php files - especially php files that contain sensitive information - have 0644 permissions? Why not set them to 0600? Wouldn't that solve the symlink issue, at least as it concerns sensitive PHP data? Other users might be able to create a symlink to the files, but they wouldn't have significant privileges to read the file. Or am I missing something else? 0 -
Perhaps I am late the party on this one. But as you've said a file-system based solution is best. So wouldn't the best solution be to educate users so that they understand file permissions? PHP files are run as the VirtualHost user, at least with suPHP and PHP-FPM, so why should php files - especially php files that contain sensitive information - have 0644 permissions? Why not set them to 0600? Wouldn't that solve the symlink issue, at least as it concerns sensitive PHP data? Other users might be able to create a symlink to the files, but they wouldn't have significant privileges to read the file. Or am I missing something else?
Educating users is important, but many hosting companies prefer to address the issue from the server-level because getting a large user-base to follow security guidelines is a difficult process. Are you suggesting that cPanel offer an opt-in feature that automatically changes the permissions on files uploaded through FTP or File Manager to a specific value based on the PHP handler that's installed? If so, you can open a feature request for this via: Submit A Feature Request Thank you.0 -
Not really suggesting a feature. I think this is more of a server administrator's discretion. But is my suggestion actually true? The whole symlink "issue" isn't so much an issue with server security, it's just a basic misunderstanding of file permissions, something that Linux already addresses. World readable files are world readable. Why get mad at the system for allowing other users to read world readable files? Granted, some files (most?) don't contain sensitive enough information to worry if they are world readable. A static .html file on your web hosting account might be world-readable... but if I go to your website and read the source... I get the same thing. Changing static files to 640 where the files are part of the nobody group doesn't change anything, because nobody has still got to be able to read the files (where nobody is the web server user). But there shouldn't be anything that sensitive in a static HTML document anyway. I think a lot of us race around trying to find a solution to a problem instead of working to understand the problem and figuring out if the problem is really the problem. 0 -
I dunno, I'd say getting people to understand that say their Wordpress config file is automatically created with "insecure" permissions is a losing battle. The fact that it's "in the manual" isn't going to change anything. Changing File Permissions " WordPress Codex "NOTE: If you installed WordPress yourself, you likely DO need to modify file permissions. Some files and directories should be "hardened" with stricter permissions, specifically, the wp-config.php file. This file is initially created with 644 permissions, and it's a hazard to leave it like that. See Security and Hardening." Regards those grsecurity cpanel-images, wasn't even aware they existed. What's the deal with what they provide there, I note Michael saying the kernels aren't updated and there isn't a patch there yet for centos 6.8... 0 -
Regards those grsecurity cpanel-images, wasn't even aware they existed. What's the deal with what they provide there, I note Michael saying the kernels aren't updated and there isn't a patch there yet for centos 6.8...
The tentative plan is to offer a simple kernel that can be used for symbolic link protection. In addition to expanding our documentation with installation instructions, we'd like to include a user interface where administrators can easily install and enable this kernel. There's currently no specific time frame we can offer on this new feature. Thank you.0 -
Hello, An unsupported fork of ea-apache2 that allows users to utilize the BlueHost Symlink Protection patch for EasyApache 4 is available at: GitHub - JPerkster/ea-apache2-bluehost This is only offered as a last resort, as the previously suggested recommendations are the preferred method of protecting against this type of attack. Thank you. 0 -
The tentative plan is to offer a simple kernel that can be used for symbolic link protection. In addition to expanding our documentation with installation instructions, we'd like to include a user interface where administrators can easily install and enable this kernel. There's currently no specific time frame we can offer on this new feature. Thank you.
That sounds great and would be something I'd support. Is there a specific place we should be indicating our enthusiasm for such?0 -
That sounds great and would be something I'd support. Is there a specific place we should be indicating our enthusiasm for such?
You could reach out to our Community Manager to offer feedback or support during the development process: Hi. I"m benny. How can I help? | cPanel Blog Thank you.0 -
As I found out earlier after penning a feature request, the patched kernel is now a thing \o/ How to Harden Your cPanel System's Kernel - cPanel Knowledge Base - cPanel Documentation With regards that page, it would be useful if it stated whether the kernel is the 'same' as the Centos source with specific grsec patch(es) applied. Purely out of interest, are you now a grsec client? It'd be nice to see your logo as a supporter of their work... I'll leave off the "full configured grsec kernel" feature request for another day ;) 0 -
Hello, The How to Harden Your cPanel System's Kernel - cPanel Knowledge Base - cPanel Documentation document was recently published with information on using the cPanel-provided kernel update on CentOS 6 64-bit systems. Please note the following caveats: [LIST] - The cPanel-provided kernel update will not work for OpenVZ", Virtuozzo", LXC, or other container-based systems.
- Do not perform these steps if you are using KernelCare", KernelSplice or similar technologies.
- cPanel & WHM does not automatically update the operating system kernel. Unattended system kernel updates may cause unplanned reboots or system failures.
Technical details about the patch itself are available within the files in the directory listing at: Index of /cpanel-images/centos_6.7_patch_and_testWith regards that page, it would be useful if it stated whether the kernel is the 'same' as the Centos source with specific grsec patch(es) applied. Purely out of interest, are you now a grsec client? It'd be nice to see your logo as a supporter of their work...
Could you elaborate on this question? Are you asking if it's an exact replica of a specific CentOS kernel with the symlink patch as the only change? Thank you.0 -
Yes exactly. The patch directory answers this question for those capable of reading it, so a link to the current one on the docs page at least would be handy but I do feel it would be worth stating in plain English. The only other question that immediately occurs as bound to arise is how much (if any) lag you expect for publishing kernel updates to your repo once these are released by upstream. Many thanks 0 -
At the risk of looking like I've completely lost the plot... is the mirror at Index of /cpanelsync/repos/CentOS/6/cPkernel/x86_64 missing the cPkernel.repo file currently? 0 -
I took a guess at the contents of the cPkernel.repo file [cpanel-kernel] name=cPanel kernel type=rpm-md baseurl=http://httpupdate.cpanel.net/cpanelsync/repos/CentOS/6/cPkernel/x86_64 gpgcheck=1 gpgkey=https://securedownloads.cpanel.net/cPanelPublicRPMKey.asc enabled=1
This worked after accepting the key and rebooting into the new kernel on a pv test vm running on Rackspace cloud.0 -
At the risk of looking like I've completely lost the plot... is the mirror at Index of /cpanelsync/repos/CentOS/6/cPkernel/x86_64 missing the cPkernel.repo file currently?
I've confirmed cPkernel.repo is missing from the download location referenced in that document. I've opened a case with our documentation team to clarify the correct download path to this file, and I'll update this thread once the updated document is published. In addition, I've asked for clarifications regarding your other questions, and I'll update this thread with more information as soon as it's available. Thank you.0 -
Hello, Yes, to update, the document is now updated to reflect the correct download path: https://securedownloads.cpanel.net/cPkernel/cPkernel.repo
Thanks!0 -
The only other question that immediately occurs as bound to arise is how much (if any) lag you expect for publishing kernel updates to your repo once these are released by upstream.
Hello @ThinIce, The plan is to have the kernel automatically apply the patch, build, and publish itself. However, this is still a work in-progress. Thank you.0 -
Not really suggesting a feature. I think this is more of a server administrator's discretion. But is my suggestion actually true? The whole symlink "issue" isn't so much an issue with server security, it's just a basic misunderstanding of file permissions, something that Linux already addresses. World readable files are world readable. Why get mad at the system for allowing other users to read world readable files? Granted, some files (most?) don't contain sensitive enough information to worry if they are world readable. A static .html file on your web hosting account might be world-readable... but if I go to your website and read the source... I get the same thing. Changing static files to 640 where the files are part of the nobody group doesn't change anything, because nobody has still got to be able to read the files (where nobody is the web server user). But there shouldn't be anything that sensitive in a static HTML document anyway. I think a lot of us race around trying to find a solution to a problem instead of working to understand the problem and figuring out if the problem is really the problem.
The symlink hack isn't just a linux file perms issue; it's an Apache issue. World readable isn't the only thing in play here. Just because a file is world readable doesn't make it open to everyone if the directory it falls under is not world readable (or technically, is not world executable). I could have a file set to 777 but if the directory it's in is 700 then only the owner of that dir can actually manipulate or read the file inside it. The issue comes in because public_html dirs are set to user:nobody, 750. In other words, not world readable. Obviously that's a good thing, however, by using apache to follow a symlink, you gain access to everything "nobody" (Apache) can read. I've worked abuse desks for a long time and this was a huge issue until the rack911/bluehost patches came along. I cannot tell you how many hours I spent restoring peoples backups or even hand cleaning code and databases. You would think that html/php files shouldn't contain sensitive data, but in the case of webapps, they almost always have the DB creds, and that's all you need to hack each site. And you can't just view-source on a php file and get code that's not programmed to display, otherwise every WP site on the internet could be hacked pretty much instantly. I know in a perfect world people would use Kernel level protections but we can't just force them on people. I know everyone calls the bluehost patch a "last resort" but believe it or not I've seen it do its job extremely well on thousands of servers. Of the many servers I cleaned/fixed before that patch, I've never had to clean one after applying that patch. I'm glad to see I can finally use ModSecurity with RUID2. This works for me on my own servers, but unfortunately, it's not a config I can force on thousands of users. I hope none of this sounds rude, just trying to clarify some things as this "hack" is frequently misunderstood. Also in reference to a previous post of yours, setting php files to 600 (at least ones like wp-config) could certainly help mitigate this. However in this case without RUID2, apache would still need read access to any files it has to serve (images etc) so those would have to be left with higher perms (not a security issue, but more an issue of confused users when php files work as 600 but other stuff doesn't).0
Please sign in to leave a comment.
Comments
27 comments