[IMPLEMENTED] Case 63676: Provide optional symlink protection patch

[JeffP.]

From today's changelog:

EasyApache < AllDocumentation/ChangeLog < TWiki

Case 63676: Provide optional symlink protection patch

 

[myusername]

Yay! Thanks guys

 

[AlexisMeroni]

How i install the patch ? :s

 

[PenguinInternet]

EasyApache, Exhaustive Options, Symlink Race Condition Protection

 

[nospa]

Please explain how is it working? What is the difference between this patch and patch provided by Rack911?

 

[AlexisMeroni]

The patch don't work :'( I return to my old safe_mode security --'

 

[nospa]

Still waiting for explanation why this patch is better - for example - than removing FollowSymLinks option from core.c in Apache?

 

[chrismfz]

Having CL with cagefs and securelinks on this still needed ?

 

[LDHosting]

Having CL with cagefs and securelinks on this still needed ?

Yes. Despite the wording, this patch does nothing to prevent Apache following symlinks when the target is owned by another user. This patch only closes a race condition. You will still need to use 3rd party patches / software or totally disable FollowSymLinks and remove it from AllowOverride in order to protect your servers.

 

[PeteN]

We attempted to add this patch via EasyApache and compile failed with mod_sec errors.

"Syntax error on line 306 of /usr/local/apache/conf/modsec/10_asl_rules.conf:
SecRule takes two or three arguments, rule target, operator and optional action list"

The rules were adjusted and the patch then applied sucessfuly.

Unfortunately my server Shared SSL certificate then stopped working (.css and .js files giving 404 errors when using shared ssl links like https://sslcertsite.com/~accountname/index.php). Which caused havok with my webstore customers till discovered and rectified.

Patch was then removed, except we had even more problems with mod_sec. So removed mod_sec profile completely and were then able to uninstall the patch.

A disaster of a weekend.

Can somebody confirm this Symlink patch does/does not stop Shared SSL certificates from working?

And it would be very much appreciated if somebody would bullet point list all the necessary actions to perform on a CentOS cPanel server running suPHP to stop the symlink exploit as best as possible at the moment? We have already done the "config files to chmod 600 (and 400 sometimes)" and I am running cxswatch to help protect the server.

Cheers,
Pete

 

[quizknows]

We attempted to add this patch via EasyApache and compile failed with mod_sec errors.

"Syntax error on line 306 of /usr/local/apache/conf/modsec/10_asl_rules.conf:
SecRule takes two or three arguments, rule target, operator and optional action list"

The rules were adjusted and the patch then applied sucessfuly.

Unfortunately my server Shared SSL certificate then stopped working (.css and .js files giving 404 errors when using shared ssl links like https://sslcertsite.com/~accountname/index.php). Which caused havok with my webstore customers till discovered and rectified.

Patch was then removed, except we had even more problems with mod_sec. So removed mod_sec profile completely and were then able to uninstall the patch.

A disaster of a weekend.

Can somebody confirm this Symlink patch does/does not stop Shared SSL certificates from working?

And it would be very much appreciated if somebody would bullet point list all the necessary actions to perform on a CentOS cPanel server running suPHP to stop the symlink exploit as best as possible at the moment? We have already done the "config files to chmod 600 (and 400 sometimes)" and I am running cxswatch to help protect the server.

Cheers,
Pete

Pete,

Your modsec compile errors are unrelated to the symlink patch. Guessing by your file names for your modsec rules, you need the newer copy of the ASL modsec rules.

With the shared SSL issue, I speculate that this patch makes it so served files have to be owned by the vhost owner, so there is a decent chance it will break things for you in that situation.

 

[quizknows]

Yes. Despite the wording, this patch does nothing to prevent Apache following symlinks when the target is owned by another user. This patch only closes a race condition. You will still need to use 3rd party patches / software or totally disable FollowSymLinks and remove it from AllowOverride in order to protect your servers.

You sure about that? I removed the 3rd party patch (Steven's patch) that I was using, and compiled apache 2.2.24 with the new "Symlink Race Condition Protection." Trying to abuse it, I get errors like this:

[Mon Mar 11 17:13:24 2013] [error] [client $myIP] Caught race condition abuser. attacker: 506, victim: 507 open file owner: 507, open file: /home/HOMEDIR1/public_html/1.txt/home/HOMEDIR2/public_html/index.html

EDIT: This patch appers to work differently than Steven's (Rack911) patch. This patch checks the files / targets of links being served to make sure they're owned by the vhost owner. With SuPHP this is no problem, however, It looks like this could cause some serious problems for people who use DSO. If I switch from SuPHP to DSO and my webapp uploads a file which is then owned by 'nobody,' this patch stops that file from being served (no symlinks involved with this test):

[Mon Mar 11 17:48:54 2013] [error] [client $myIP] Caught race condition abuser. attacker: 506, victim: 99 open file owner: 99, open file: /home/HOMEDIR/public_html/blog/apachetest.html

If you don't use SuPHP, Steven's patch is still probably a better option.

 

[LDHosting]

You sure about that?

I checked with cPanel support and they advised that this only closes the race condition.

"Could you please tell me, does this only close the SymLinksIfOwnerMatch race condition, or does this also force SymLinksIfOwnerMatch or otherwise prevent Apache from following symlinks where the target is owned by another user?"

I have been researching this issue for you. In going over the internal notes for 63676 and this patch only applies the fix for the race condition. It does not force the usage of SymLinksIfOwnerMatch nor does it disable the usage of FollowSymLinks. I ran this in my build in my test environment to ensure that this was the case.

I would agree that the wording in the EA changelog may be viewed as misleading, and am submitting this to our documentation team for further review.

Can cPanel please confirm what this patch ACTUALLY does? It seems that the changelog says 1 thing, support says another and someone's experience says yet another.

 

[quizknows]

LDHosting, if you run an EA with the patch selected, it leaves it behind after the build. You can read it yourself:
/home/cpeasyapache/src/cppatch/symlink-protection.patch

It seems they used a page out of this book: Introducing SecureLinks for Apache

"note that ALL static files have to be owned by user for them to be served. Any files owned by root, or any other user will result in Access Denied when SecureLinks are enabled. " <- is exactly what I exprienced. This is a pretty backwards way to patch this IMO. "it makes sure that the file that will be served by Apache is owned by the same user, as the owner of VirtualHost. We pick up the owner of virtual host from SuexecUserGroup directive." In other words, if you're using DSO, you're going to have a bad time.

Correct me if I'm wrong, but my brief experience with this patch, and my quick reading of the code in the patch file seems to back the above information. In all technicality it doesn't touch followsymilnks or symlinksifownermatch themselves, but it does stop apache from serving any files (or link target files) that aren't owned by the vhost owner.

I can't tell you where I work, but we have thousands and thousands of cPanel servers. I've already had 5 servers this week with every single wordpress site defaced via symlink. For the last month we've probably had an average of 3 customers per day who wake up to find every WP/joomla site hacked on their box because of this. I've been installing (and will continue to install) the rack911 patch to prevent this, and it's doing a fine job.

 

[AlexisMeroni]

Why you don't use a security with safe_mode or with CLOUDLINUX & CageFS ?

 

[quizknows]

Shared hosting environments we do use Cloudlinux. However, not all dedicated server customers want cloudlinux and most just use centOS with cPanel. For those servers, a patch is needed to prevent mass-defacing of CMS sites if one users CMS gets compromised.

 

[myusername]

hello,
chicken wire mesh

Something tells me this thread is not getting much attention.

 

[ikillbill]

Hi
We are also curious about how this works with rack911 's Steven 's patch please?

maybe this post is on wrong forum? not much involvements~

 

[ThinIce]

Hi
We are also curious about how this works with rack911 's Steven 's patch please?

maybe this post is on wrong forum? not much involvements~

It's an either or per cPanel's documentation at Symlink Race Condition Protection

Warning: If you already use a custom patch for the race condition (for example: FollowSymLinks_twnerMatch.patch), you will need to either remove your custom patch or not enable the Symlink Race Condition Protection option in EasyApache.

 

[KurtN.]

We've updated the Symlink Race Condition Protection documentation to better reflect what the new patch does, and how it affects you. Please take a gander.