[prev in list] [next in list] [prev in thread] [next in thread] 

List:       samba-technical
Subject:    Re: Claimed Zero Day exploit in Samba.
From:       Michael Gilbert <michael.s.gilbert () gmail ! com>
Date:       2010-02-05 20:48:37
Message-ID: 20100205154837.71cbc3b4.michael.s.gilbert () gmail ! com
[Download RAW message or body]

On Fri, 5 Feb 2010 12:16:33 -0800, Jeremy Allison wrote:
> On Fri, Feb 05, 2010 at 03:09:06PM -0500, Michael Gilbert wrote:
> > Jeremy Allison wrote:
> > > As an example, given a share definition:
> > >
> > > [tmp]
> > > 	path = /tmp
> > >	read only = no
> > >	guest ok = yes
> > >
> > > The administrator could add a symlink:
> > >
> > > $ ln -s /etc/passwd /tmp/passwd
> > > 
> > > and SMB/CIFS clients would then see a file called "passwd"
> > > within the [tmp] share that could be read and would allow
> > > clients to read /etc/passwd.
> > [...]
> > > All future versions of Samba will have the parameter
> > > "wide links" set to "no" by default, and the manual
> > > pages will be updated to explain this issue.
> > 
> > while more secure (hardened) defaults are good, wouldn't it be more
> > effective to tackle the root cause of the problem?  i.e. on the samba
> > server side, detect attempts by remote users to create symlinks to
> > targets outside of their authorized shares and prevent that.
> 
> That code already exists and will be turned on when "wide links = no"
> is set.

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

> The problem is that's not what you want. There are valid reasons
> for Linux / UNIX clients to create symlinks on a remote file system
> that point to local files (/etc/passwd).

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

thanks for your quick reply.  

best wishes,
mike
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic