jimlongo

Well-Known Member
Mar 20, 2008
253
21
68
I've just upgraded to EA4 and feel newly vulnerable.

The documentation leads me to believe that if in Home -> Apache Configuration -> Global Options -> Directory Options
I have SymLinksIfOwnerMatch ON and FollowSymLinks OFF that I am not subject to the SymLink Race Condition.

I'm on a linux server (mod_security/su_execPHP), do I also need to implement the GRSec kernel patch?

I'm confused as FollowSymLinks and SymLinksIfOwnerMatch are both labelled as default.
 

jimlongo

Well-Known Member
Mar 20, 2008
253
21
68
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.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463
Last edited:

jimlongo

Well-Known Member
Mar 20, 2008
253
21
68
My VPS provider has advised me that the only solution seems to be to revert to EA3.
Any thoughts on that?
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463
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:

https://grsecurity.net/cpanel-images/centos_6.5_patch_and_test/symlinkown.patch

The upstream CentOS 7 kernel does not include this patch, and there are no patched kernels available for CentOS 7 at this time, but research into such a patch for CentOS 7 from GRSec is underway. There's no time frame on it's availability at this time.

Thank you.
 

jimlongo

Well-Known Member
Mar 20, 2008
253
21
68
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.
 

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
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.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463
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.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,051
232
368
cPanel Access Level
Root Administrator
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?
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463
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.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,051
232
368
cPanel Access Level
Root Administrator
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.
 
  • Like
Reactions: cPJacob and w2b

ThinIce

Well-Known Member
Apr 27, 2006
352
9
168
Disillusioned in England
cPanel Access Level
Root Administrator
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...
 
Last edited:

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463
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.
 
  • Like
Reactions: ThinIce

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463
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.
 
  • Like
Reactions: RWH Tech

ThinIce

Well-Known Member
Apr 27, 2006
352
9
168
Disillusioned in England
cPanel Access Level
Root Administrator
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?
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463

ThinIce

Well-Known Member
Apr 27, 2006
352
9
168
Disillusioned in England
cPanel Access Level
Root Administrator
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 ;)
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,904
2,226
463
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:

  • 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_test

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...
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.