How to Prevent Creating Symbolic Links for non root users?

[Bullten]

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]

It works for me (Apache/2.2.21) with following configuration without any patch or did I miss something?

<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

[~/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

# cat .htaccess 
Options +FollowSymLinks 

Result 1:Symbolic link not allowed or link target not accessible: /home/super/public_html/slink

Testcase 2

# cat .htaccess 
Options +FollowSymLinks -SymLinksIfOwnerMatch

Result 2: /home/super/public_html/.htaccess: Option SymLinksIfOwnerMatch not allowed here

Testcase 3

# cat .htaccess 
#empty

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

[DomineauX]

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]

Look at the file (777) in the same folder.

[~/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

[DomineauX]

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]

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>]

[DomineauX]

Confirmed in 2.2.17 thanks.

[Davetha]

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.

[jandafields]

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?

[Davetha]

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.

[jandafields]

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]

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]

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...

[spork985]

I'm confused after reading this thread. Could someone please sum up which solution works in Apache 2.2.22.

Thanks

[bmthads]

i have a hacked site can anyone help to prevent cym links
i still have the active sym link they are using