Solutions for handling symlink attacks
- Thread starter HostingH
- Start date
- Status
- Not open for further replies.
well to stop symlink just create a cron job to change permission of all config files on server with 600. This will do the trick and stop symlink.
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.
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:
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.
No need to run several times a day just twice or thrice per week.
It works for me (Apache/2.2.21) with following configuration without any patch or did I miss something?
- allows FollowSymLinks in .htaccess and doesn't break joomla etc
- disallow SymLinksIfOwnerMatch in .htaccess
Testcase 1
Testcase 2
Testcase 3
Code:
<Directory "/">
Options +ExecCGI +FollowSymLinks -Includes +IncludesNOEXEC +Indexes -MultiViews +SymLinksIfOwnerMatch
AllowOverride AuthConfig FileInfo Indexes Limit Options=Indexes,FollowSymLinks
</Directory>- 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*
Code:
# cat .htaccess
Options +FollowSymLinks
[I]Result 1:Symbolic link not allowed or link target not accessible: /home/super/public_html/slink[/I]
Code:
# cat .htaccess
Options +FollowSymLinks -SymLinksIfOwnerMatch
[I]Result 2: /home/super/public_html/.htaccess: Option SymLinksIfOwnerMatch not allowed here[/I]
Code:
# cat .htaccess
#empty
[I]Result 3: Symbolic link not allowed or link target not accessible: /home/super/public_html/slink[/I]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>
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>
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:
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.
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.
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>]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.
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:
Please clarify. Does this mean that we still need to use the StevenC patch, or no longer need to use the StevenC patch?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:
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.Please clarify. Does this mean that we still need to use the StevenC patch, or no longer need to use the StevenC patch?
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:
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?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.
That is what I've been trying to say. It doesn't protect you from the other vulnerability.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?
Actually, we are running 2.2.22 and the directives work, but as before, break Joomla or anyone else having +FollowSymlinks in their .htaccess.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.
Put on the patch and now all is right...
I'm confused after reading this thread. Could someone please sum up which solution works in Apache 2.2.22.
Thanks
Thanks
- Status
- Not open for further replies.
