Claimed Zero Day exploit in Samba.

[Michael Gilbert]

On Fri, 5 Feb 2010 12:46:06 -0800, Jeremy Allison wrote:
> On Fri, Feb 05, 2010 at 03:48:37PM -0500, Michael Gilbert wrote:
> > 
> > in your original description, you stated that "wide links = no" will
> > generate an "access denied" error when a "wide link" is accessed;
> > however, you didn't mention that creation of "wide links" is also
> > prevented.  if this is true, then that is a very satisfactory
> > solution.
> 
> No, it's actually incorrect. If "wide links = no", then no
> one can ever access anything off share, and so UNIX symlinks
> should be allowed to point to anywhere they like, as UNIX
> clients will follow them locally, not on the server.
> 
> > however, i think that the prevention code itself already
> > solves the root of the issue, and enabling that by default would fully
> > solve the problem.
> 
> Nope - see above :-).
> 
> > i can understand giving the local administrator this capability.
> > however, i don't see the need for remote users to have such authority
> > (although any enlightenment would be very much appreciated).
> 
> Imagine an app running on a Linux client that needs a symlink
> to /usr/local/lib inside it's filespace (don't know why, but
> it might :-). If that app is run off a CIFSFS share creating
> the /usr/local/lib symlink would fail with "wide links = no",
> which is not what you want.

thinking about this some more.  

if "wide links = no" is the chosen solution, then for this use case
the user needs to set "wide links = yes" to get this to work, and then
they are vulnerable to the security issue, which is bad.

on the other hand, if remote "wide link" prevention is the chosen
solution, then this use case is supported and the user is concurrently
protected from the security issue.  however, it adds the additional
tedium of getting authorization from the samba administrator to create
the symlink.

mike