Solutions for handling symlink attacks

[nospa]

Thanks quizknows. This is exactly what I think.

 

[abdelhost77]

Is there a way to downgrade from APACHE 2.2.24 to APACHE 2.2.23

Because Easyapache , dont provide apache 2.2.23 in suggested apache versions .

And i want to continu to use Rack911 pacth on Apache 2.2.23 , because it seems that Rack911 patch does not work on Apache 2.2.24

Thanks a lot

 

[tizoo]

Hi everyone,

We have just been hit by the "tar" version of this hack on one of our servers. As others have pointed out, the problem is fixed if one changes the permissions on the configuration files (wp-config.php, configuration.php, etc...).

We are using suphp and I was wondering if simply changing the permissions on all php files like this would solve the problem :

find /home/ -type f -name '*.php' -print0 | xargs -0 chmod o=

PHP files wouldn't be readable by other users anymore, even if they are able to make symlinks to them.

In addition to the patch to apache, I think this would make things a bit more secure.

Do you see any drawbacks from using this ?
Thanks in advance for your feedback,
Kind regards,
Florian

 

[quizknows]

Is there a way to downgrade from APACHE 2.2.24 to APACHE 2.2.23

Because Easyapache , dont provide apache 2.2.23 in suggested apache versions .

And i want to continu to use Rack911 pacth on Apache 2.2.23 , because it seems that Rack911 patch does not work on Apache 2.2.24

Thanks a lot

Rack911 patch works fine as-is on 2.2.22 through 2.2.24. The files it patches are the same between those versions.

 

[mtindor]

Rack911 patch works fine as-is on 2.2.22 through 2.2.24. The files it patches are the same between those versions.

Unless something changed [and i haven't checked in the past month], the patch "as is" doesn't work on 2.2.24 even though it's patching the same file . That's because the patch references the 2.2.23 directory. If the patch is not downloaded and the directory references changed to 2.2.24, the patch will not complete if you're compiling 2.2.24 with EA.

I download and store a local copy of the patch on one of my own servers. Then I modify the patch to reference the correct directory structure. Then I modify /scripts/before_apache_make to download the local patch [that has been modified for 2.2.24] from my local server.

M

 

[quizknows]

the patch uses the -p1 flag, so it ignores paths up to the first /

editing it works, but is unnecessary.

 

[mtindor]

the patch uses the -p1 flag, so it ignores paths up to the first /

editing it works, but is unnecessary.

Must be a new patch compared to the one originally used on 2.2.22, because back when 2.2.23 came out the patch did not work on 2.2.23 without editing. Although one would never know it unless they specifically checked the EA build log to see that it didn't patch.

Mike

 

[KurtN.]

Hi mtindor,

If I'm understanding you correctly, you're saying the Symlink [Rack911] patch doesn't apply at all on Apache 2.2.24 without modification?

I'm unable to duplicate that issue.

If I'm understanding you correctly, could you submit a ticket to support, then let me know the ticket id?

Thanks

 

[mtindor]

Kurt,

I can't say that _now_. Back when the patch was originally released, it was for 2.2.22. Then when Apache 2.2.23 came out, those wanting to use the patch from Rack911 had to edit the patch to change references of 2.2.22 to 2.2.23. When 2.2.24 came out, I automatically did that same thing.

Now, when I go look at the patch available at Rack911, it appears to be different than the one I originally downloaded from there. the original one referenced 2.2.22.

So maybe the ccurrent patch off of rack911.com works just fine on 2.2.24. I can't say for sure. I just know that I edited it instinctively when I went to compile 2.2.24 a week or two ago.

I can only say with any confidence that the originally released patch (meant for 2.2.22) would not install on 2.2.23 or 2.2.24 without modification.

mike

Hi mtindor,

If I'm understanding you correctly, you're saying the Symlink [Rack911] patch doesn't apply at all on Apache 2.2.24 without modification?

I'm unable to duplicate that issue.

If I'm understanding you correctly, could you submit a ticket to support, then let me know the ticket id?

Thanks

 

[dbcorp]

so quickly scanning this thread and others on this topic on the net i get conflicting views on this

one says cpanel has implemented a patch yet in some recent posts here in the thread cpanel staff say to use the rack911 patch

so which is it, and why didnt cpanel patch this long ago?

 

[quizknows]

so quickly scanning this thread and others on this topic on the net i get conflicting views on this

one says cpanel has implemented a patch yet in some recent posts here in the thread cpanel staff say to use the rack911 patch

so which is it, and why didnt cpanel patch this long ago?

Which patch you use is up to you. The Rack911 works regardless of PHP handler, the cPanel patch will give you problems if you're not using SuPHP.

cPanel didn't patch this "long ago" because it's an apache issue, not a cPanel issue. I'm glad to see any support out of them for it though, becuase hackers specifically target cPanel servers with these attacks.

For the probably 100th time, I wish they'd just have both patches available in EA. It's really the sensible option here.

Also, I can confirm that the rack patch works just fine on 2.2.22 through 2.2.24 without editing, I've installed it on countless servers and verified success in the EA build log. The -p1 flag has alwasy been on the /usr/bin/patch command, and if you read the man page for 'patch' it will explain that this strips the paths up to the first '/'. This means that this:

httpd-2.2.23.orig/include/http_core.h

becomes:

include/http_core.h

Steven (who wrote the patch) explained this to me.

 

[pjman50]

Has a patch been provided for this or no or should the rack911 patch be used?

 

[quizknows]

cPanel has provided a patch, but it's functionally different than the rack911 patch, and quite frankly it seems like over-kill to me and not directly targeted at the symlink issue.

The rack911 patch turns FollowSymlinks into SymlinksIfOwnerMatch. I personally much prefer that patch, and it has served me well on hundreds of servers.

The new patch from cPanel available in EA ("Symlink race condition patch") checks files as they're served (whether they're symlinked to or not) to see if they're owned by the vhost owner. If a file is not owned by the user account that owns the vhost, the file will not be served. This works OK with SuPHP because all the files are owned by the user account anyway, but it will cause problems with other PHP handlers if files are owned by the webserver (i.e. "nobody" owned files). It also likely will cause a decrease in server performance.

 

[Nishant80]

Sorry for the newbie question. I've installed rack911's patch. Now how do I ensure its working fine? (I am not sure how to create a symlink) still in learning phase.

Also, whats the best way to fix the sites that were already hacked?

 

[quizknows]

You need to restore the hacked sites to a clean backup. If you don't have backups, you need to have the users change all administrative passwords for the CMS, remove and re-install any themes and plugins (the attackers usually edit theme and plugin files to put backdoors in them), and run clamscan and/or maldet on the account. Best course of action is a reinstall or restore from backup.

To ensure the patch is installed properly, do something like this (you'll have to log in to SSH).

Log in to ssh as username1, and run these commands:

cd ~/public_html
ln -s /home/username2/public_html/index.php testlink.txt

Navigate to the domain for username1:
username1.com/testlink.txt

the Apache error log should show:

[Fri Apr 26 20:34:48 2013] [error] [client your.ip.address] Symbolic link not allowed or link target not accessible: /home/username1/public_html/testlink.txt


It would be easier to check the log file as root:

[[email protected] /usr/local/cpanel/logs/easy/apache]# grep before_apache_make *
build.1366237575:!! Executing custom hook '/scripts/before_apache_make' !!
build.1366237575:!! Done executing '/scripts/before_apache_make' !!

 

[egillette]

I run DSO and MOD_RUID2 so that all files are owned by the user, and executed as such too.

Is that why I have yet to run into the problem being described here??

I host around 4,000 or so sites for various clients. Just curious, if I should be looking out for this or not. . .

 

[cPanelNick]

The rack911 patch turns FollowSymlinks into SymlinksIfOwnerMatch. I personally much prefer that patch, and it has served me well on hundreds of servers.

Turning FollowSymlinks into SymlinksIfOwnerMatch would likely not be sufficient to fully address this problem as there is a period between when the owner is checked and the file is served that can be attacked. It might be good enough for your needs though.

I run DSO and MOD_RUID2 so that all files are owned by the user, and executed as such too.

If you are concerned, you might be better off upgrading to 11.38 and turning on apache jails so that each vhost runs inside its own chroot() which makes this problem moot.

 

[myusername]

Hi Nick,

To be clear, does Apache Jails fix "the period between when the owner is checked and the file is served" or the entire overlying symlink issue?

 

[cPanelNick]

Hi Nick,

To be clear, does Apache Jails fix "the period between when the owner is checked and the file is served" or the entire overlying symlink issue?

When enabled the user will only see what they see in jailshell. They won't be able to see any of the other users on the system home dirs.

 

[AlexAT]

...you might be better off upgrading to 11.38 and turning on apache jails so that each vhost runs inside its own chroot() which makes this problem moot.

Is this new option? Where I can find it to enable for suphp?
What about performance ?