Solutions for handling symlink attacks

[activa]

this will not take effect if nginx is installed .

 

[SoftDux]

Ok, so just to confirm. What can actually protect a cPanel Apache server, without breaking thousands of Joomla (and possibly others?) sites on the server?

P.S. I have read through the whole posts, but there's some conflicting "advice" here, and nothing concrete - or even a definite fix from the cPanel folk.

 

[SoftDux]

I see the CloudLinux project has something called SecureLinks which should fix this very problem, but it's not available on cPanel yet (even though it's available on Plesk, InterWorx and and ISPManager.

* We are working with cPanel to include new version of mod_hostinglimits with SecureLinks enabled in the next EasyApache release.

So, when can we expect this in cPanel? That post was made in February already, which means it has been working on the other control panels before February. Yet, 3 months later and it's still not available in cPanel

 

[DomineauX]

Apache has already incorporated a fix for the race condition:

Got a tip .. changelog apache 2.2.17

*) core: check symlink ownership if both FollowSymlinks and
     SymlinksIfOwnerMatch are set [Nick Kew]

 *) core: fix origin checking in SymlinksIfOwnerMatch
PR 36783 [Robert L Mathews <rob-apache.org.bugs tigertech.net>]

 

[Arun]

^^ cPanel uses Apache 2.2.22 now.

So if both FollowSymlinks and SymlinksIfOwnerMatch are disabled in Apache Configuration will this be resolved?

 

[SoftDux]

will this be resolved?

No, it isn't resolved.

 

[Arun]

Ok, will try Steven's patch then

 

[Mitio]

Hello,

If you have any problem with the patch >> - for Apache/2.2.22 please add me on skype my skype name: nasanet. I will create a detailed guide as soon as possible.

Best Regards,
Dimitar Spasov,

 

[abdelhost77]

I install the patch and it work like a charm in our servers , now a hacker cannot use the symlink scripts to open Joomla or Wordpress configuration file , even if the config file is chmoded to 644 or higher ( if it is 640 than even if the patch is NOT installed a hacker cannot read the file using the symlink trick ) .

The question now , is HOW to be sure that this patch will not be overriden by APACHE or CPANEL automatic Updates , any IDEA PLEASE ?

 

[rlshosting]

You could disable symlinks in disable_functions in php.ini.

 

[Prateek]

it won't help ^^^

best solutions are

option 1 - GO with Cloud linux dam good

Option 2 - Go with http://forums.cpanel.net/f185/how-p...inks-non-root-users-202242-p4.html#post996441 solution both run more then fine

 

[rlshosting]

That's lame. It should be already patched up.

 

[optize]

cPanel -

Why isn't this fixed yet? This seems like a really simple fix, especially since Steven has done the work for you. I can't imagine how many thousands of cPanel boxes out there that are vulnerable to this since cPanel's not making a big deal out of it.

 

[cPanelTristan]

There is a current implementation where you can already do this otherwise. If you switch to using mod_ruid2 and setup RDocumentChRoot, it will chroot the user into their directory and symlinks cannot be followed at that point.

 

[hostnex]

There is a current implementation where you can already do this otherwise. If you switch to using mod_ruid2 and setup RDocumentChRoot, it will chroot the user into their directory and symlinks cannot be followed at that point.

You should also inform them about the draw backs of the Mod Ruid.

Mod Ruid will break most of your scripts specially wodress and joomal also mysql will stop working through hostnames. Alot of other issues as well. I did open ticket on cpanel and i was informed that they cant fix it as mod ruid is not their product. Instead of Mod ruid I will recommend all to install CAGEFS of Cloud Linux that virtually makes impossoiebl for hackers to make symlink with root also apply steven patch whch will make it more harder for the hackers to symlink.

Here is the direct link of CagFS

CageFS 3.5

 

[cPanelTristan]

Actually WordPress functions under mod_ruid2 if you use 127.0.0.1 for the database connection in the setup. Joomla forces use of /tmp and won't allow setting it to another location. WordPress will not fail if you set /tmp somewhere else. I tested WordPress installs on mod_ruid2 for benchmark testing with my /home/username/public_html chrooted and it worked just fine.

 

[brianoz]

The question now , is HOW to be sure that this patch will not be overriden by APACHE or CPANEL automatic Updates , any IDEA PLEASE ?

See http://forums.cpanel.net/f185/how-p...inks-non-root-users-202242-p2.html#post996441 (direct link to article 54, before_apache_make) - it should reapply the patch whenever you run easyapache ...

 

[d'argo]

Is there a performance penalty if you use the patch?

 

[StevenC]

I have been talking with Brad from Grsecurity about this issue and he recently introduced a new feature to help mitigate the race conditions associated with this problem. I am currently testing this out right now for possible roll out to all of our customers.

Here is the commit from Brad:

commit 067ede10755d38e4c6502dbfbed3992206d190c0
Author: Brad Spengler <[email protected]>
Date: Mon Jul 2 18:36:51 2012 -0400

Introduce kernel-enforced SymlinksIfOwnerMatch feature
(Highly desirable feature for webhosting companies)

Conflicts:

fs/namei.c

fs/namei.c | 11 +++++++++++
fs/udf/super.c | 6 +++---
grsecurity/Kconfig | 27 ++++++++++++++++++++++++++-
grsecurity/grsec_init.c | 6 ++++++
grsecurity/grsec_link.c | 16 ++++++++++++++++
grsecurity/grsec_sysctl.c | 18 ++++++++++++++++++
include/linux/grinternal.h | 2 ++
include/linux/grmsg.h | 1 +
include/linux/grsecurity.h | 1 +
security/Kconfig | 11 +++++++++++
10 files changed, 95 insertions(+), 4 deletions(-)

Apache's SymlinksIfOwnerMatch option has an inherent race condition │
│ that prevents it from being used as a security feature. As Apache │
│ verifies the symlink by performing a stat() against the target of │
│ the symlink before it is followed, an attacker can setup a symlink │
│ to point to a same-owned file, then replace the symlink with one │
│ that targets another user's file just after Apache "validates" the │
│ symlink -- a classic TOCTOU race. If you say Y here, a complete, │
│ race-free replacement for Apache's "SymlinksIfOwnerMatch" option │
│ will be in place for the group you specify. If the sysctl option │
│ is enabled, a sysctl option with name "enforce_symlinksifowner" is │
│ created.

 

[d'argo]

just found out that our atomic linux kernel already has the gsecurity kernel patch you mentioned above, it works fine btw, no performance issues and stops the symlinks. no idea if the apace patch has a performance impact but the kernel patch does not