Re: [Radmind-devel] Symlink bug on Tiger

[Wesley C. <we...@um...>]

The article cited suggests using mkdir to defeat symlink attacks,  
which works, to quote the article, "on every decent operating system  
that deserves to be called Unix-like."  Similarly, "on every decent  
operating system that deserves to be called Unix-like," symlink  
permissions are unspecified.  See:

	http://www.opengroup.org/onlinepubs/009695399/functions/lstat.html

I'm very interested in the privilege escalation attack that "every  
decent operating system that deserves to be called Unix-like" must be  
vulnerable to, since exactly ZERO of them behave like Mac OS X.

:wes

Ray SAMPSON wrote:
> Please know, symbolic link stat information changed in 10.4.  Prior  
> to 10.4,
> we did not support the concept of link stat information in HFS  
> separate from
> the containing directory cnode.  With the addition of lchown(2) et.  
> al., we
> now support this, and, like any other cnode, creation permissions  
> are for HFS
> impacted by the umask.
>
> The security purpose in doing this is to permit the creation of a  
> link with no
> permissions, with a subsequent drop of privileges after the link  
> target is
> created.  Failure to do this leads to race conditions which can  
> otherwise
> permit privilege escalation attacks.
>
> For more information, please see:
>
> http://www.linuxsecurity.com/content/view/115462/151