Solutions for handling symlink attacks

Status
Not open for further replies.

expssh

Registered
Aug 5, 2011
3
1
53
WoW!. Looks like after half of year, somebody understand what I'm showed. Not bad, not bad. :D
 

CoolMike

Well-Known Member
Sep 6, 2001
313
0
316
I just installed the patch from StevenC. Unfortuantely it's still possible to follow symlinks.

Should the patch work for Apache/2.2.21?
 

Davetha

Member
PartnerNOC
Jun 6, 2006
9
0
151
Sure making a cron to change the permissions of the users config files will work as a band-aid, but you are bound to miss some of the config files by doing that. Plus it would be fairly resource intensive to run that on a box several times a day... as well as many other points.

Sure you can turn FollowSymlinks into SymLinksIfOwnerMatch, we released a beta patch a few years ago to do that. Please note, this patch has been developed and improved since this original beta.
(Bugtraq: Apache directory traversal on shared hosting environment.)

But there is another issue, like many applications, Apache suffers from a time-of-check, time-of-use race condition that they will unlikely change any time soon.

Basically the most simple way to explain this race condition is the following..
Apache checks that the file you are requesting is infact a file... If its a file, it then reads it.
So it checks, then reads it.. This can be exploited by having a real file/dir, and creating a sym link in its place after the time it checks the file, but before it reads it.

Using openat, instead of open in Apache might resolve the race condition, but there are a handful of applications that are vulnerable to these types of race conditions. Openat wasn't added into the Linux kernel until 2.6.16, and is pretty much only avaliable in Linux, which means a lot of applications may not use openat, since it would require extra flags to be checked etc..

In the mean time its probably best to use a Kernel patch to disallow users from creating symlinks to files/dirs they don't own/don't exist.
 
Last edited:

Bullten

Member
Dec 31, 2011
5
0
51
cPanel Access Level
Root Administrator
Well you have to make a cron job that makes the correct permission for the right file. Suppose its whmcs configuration.php then it can have 700 max. So it depends on how you are going to make it.

No need to run several times a day just twice or thrice per week.
 

Rubas

Well-Known Member
Sep 15, 2003
125
0
166
It works for me (Apache/2.2.21) with following configuration without any patch or did I miss something?

Code:
<Directory "/">
   Options +ExecCGI +FollowSymLinks -Includes +IncludesNOEXEC +Indexes -MultiViews +SymLinksIfOwnerMatch
   AllowOverride AuthConfig FileInfo Indexes Limit Options=Indexes,FollowSymLinks
</Directory>
- allows FollowSymLinks in .htaccess and doesn't break joomla etc
- disallow SymLinksIfOwnerMatch in .htaccess

Code:
[~/public_html]# ls -lsa
0 lrwxrwxrwx  1 super super     5 Feb  7 15:32 slink -> test2*
4 -rwxrwxrwx  1 root  root      9 Feb  7 15:29 test2*
Testcase 1
Code:
# cat .htaccess 
Options +FollowSymLinks 

[I]Result 1:Symbolic link not allowed or link target not accessible: /home/super/public_html/slink[/I]
Testcase 2
Code:
# cat .htaccess 
Options +FollowSymLinks -SymLinksIfOwnerMatch

[I]Result 2: /home/super/public_html/.htaccess: Option SymLinksIfOwnerMatch not allowed here[/I]
Testcase 3
Code:
# cat .htaccess 
#empty

[I]Result 3: Symbolic link not allowed or link target not accessible: /home/super/public_html/slink[/I]
 

DomineauX

Well-Known Member
PartnerNOC
Apr 12, 2003
429
11
168
Houston, TX
cPanel Access Level
Root Administrator
Rubas, you are most likely symlinking to a file that is not world readable so it would not work.
Chmod the file 444 or higher and it would work if FollowSymLinks is enabled.

The solution is to disable FollowSymLinks but enable SymLinksIfOwnerMatch such as:

<Directory "/home">
Options +All +ExecCGI -FollowSymLinks +Includes +IncludesNOEXEC -Indexes -MultiViews +SymLinksIfOwnerMatch
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
 

Rubas

Well-Known Member
Sep 15, 2003
125
0
166
Look at the file (777) in the same folder.

Code:
[~/public_html]# ls -lsa
0 lrwxrwxrwx  1 super super     5 Feb  7 15:32 slink -> test2*
4 -rwxrwxrwx  1 root  root      9 Feb  7 15:29 test2*

[~/public_html]# cat slink 
password
[~/public_html]# whoami
super
 
Last edited:

DomineauX

Well-Known Member
PartnerNOC
Apr 12, 2003
429
11
168
Houston, TX
cPanel Access Level
Root Administrator
Ah sorry I missed that.
Looks like your Apache version is properly respecting the combination FollowSymLinks and SymLinksIfOwnerMatch in which SymLinksIfOwnerMatch takes priority.
I'm not sure when this would have been corrected but have not seen any notice.
 

Rubas

Well-Known Member
Sep 15, 2003
125
0
166
Got a tip .. changelog apache 2.2.17

Code:
*) 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>]
 

Davetha

Member
PartnerNOC
Jun 6, 2006
9
0
151
This patch most likely won't fix the time of check, time of use race condition, which will produce the same affect as having having just FollowSymlinks enabled.

Infact you can do it by disabling symlinks in Apache completely.

This is great that Apache finally added the patch in after 3 years.
 
Last edited:

jandafields

Well-Known Member
May 6, 2004
436
6
168
USA
cPanel Access Level
Root Administrator
This patch most likely won't fix the time of check, time of use race condition, which will produce the same affect as having having just FollowSymlinks enabled.

Infact you can do it by disabling symlinks in Apache completely.

This is great that Apache finally added the patch in after 3 years.
Please clarify. Does this mean that we still need to use the StevenC patch, or no longer need to use the StevenC patch?
 
Last edited:

Davetha

Member
PartnerNOC
Jun 6, 2006
9
0
151
Please clarify. Does this mean that we still need to use the StevenC patch, or no longer need to use the StevenC patch?
From the change log, it looks like the functionallity change Apache did, may help in a lot of ways. If you disallow your users from changing the options, then you probably don't need the patch any more. However its probably still a good idea to use.

After this are you still vulnerable? Yes. You are vulnerable to a different type of symlink attack. I'd rather not post a proof of cencept here since it would put hosts at risk. Apache is aware of the issue, but its probably unlikely they will change the code any time soon.

Its a little harder to exploit, however still very easily done, and likely to be used in the future when hosts start patching/updating Apache.
 
Last edited:

jandafields

Well-Known Member
May 6, 2004
436
6
168
USA
cPanel Access Level
Root Administrator
From the change log, it looks like the functionallity change Apache did, may help in a lot of ways. If you disallow your users from changing the options, then you probably don't need the patch any more. However its probably still a good idea to use.

After this are you still vulnerable? Yes. You are vulnerable to a different type of symlink attack. I'd rather not post a proof of cencept here since it would put hosts at risk. Apache is aware of the issue, but its probably unlikely they will change the code any time soon.

Its a little harder to exploit, however still very easily done, and likely to be used in the future when hosts start patching/updating Apache.
Thank you for that information. Regarding the second vunerability that still exists, I understand why you don't want to disclose the details. However, can you tell us if the StevenC patch protects against that vunerability?
 

Davetha

Member
PartnerNOC
Jun 6, 2006
9
0
151
Thank you for that information. Regarding the second vunerability that still exists, I understand why you don't want to disclose the details. However, can you tell us if the StevenC patch protects against that vunerability?
That is what I've been trying to say. It doesn't protect you from the other vulnerability.
 

SeanP

Registered
PartnerNOC
Jan 14, 2009
3
0
51
From the change log, it looks like the functionallity change Apache did, may help in a lot of ways. If you disallow your users from changing the options, then you probably don't need the patch any more. However its probably still a good idea to use.

After this are you still vulnerable? Yes. You are vulnerable to a different type of symlink attack. I'd rather not post a proof of cencept here since it would put hosts at risk. Apache is aware of the issue, but its probably unlikely they will change the code any time soon.

Its a little harder to exploit, however still very easily done, and likely to be used in the future when hosts start patching/updating Apache.
Actually, we are running 2.2.22 and the directives work, but as before, break Joomla or anyone else having +FollowSymlinks in their .htaccess.

Put on the patch and now all is right...
 
Status
Not open for further replies.