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

List:       samba-technical
Subject:    Re: Claimed Zero Day exploit in Samba.
From:       Jeremy Allison <jra () samba ! org>
Date:       2010-02-05 20:16:33
Message-ID: 20100205201633.GD4353 () samba1
[Download RAW message or body]

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.

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

In the short term, "wide links = no" is what you need. I'm
addressing this in code (correct parameter checks) as well,
but that's obviously a longer term change.

Jeremy.
[prev in list] [next in list] [prev in thread] [next in thread] 

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