samba - Feb 2010 - Claimed Zero Day exploit in Samba.

Claimed Zero Day exploit in Samba.

A user named "kcopedarookie" posted what they claim to
be a video of a zero-day exploit in Samba on youtube
yesterday here:

http://www.youtube.com/watch?v=NN50RtZ2N74&aia=true

The video shows modifications to smbclient allowing
/etc/passwd to be downloaded from a remote server.

The issue is actually a default insecure configuration
in Samba.

Quick FAQ: What do I do !
-------------------------

Set:

wide links = no

in the [global] section of your smb.conf and restart
smbd to eliminate this problem.

Longer FAQ: The real issue
--------------------------

The problem comes from a combination of two features in
Samba, each of which on their own are useful to Administrators,
but in combination allow users to access any file on the system
that their logged in username has permissions to read (this is
not a privilege escalation problem).

By default Samba ships with the parameter "wide links = yes",
which allows Administrators to locally (on the server) add
a symbolic link inside an exported share which SMB/CIFS clients
will follow.

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.

If the "wide links" parameter is set to "no", any attempt
to read this file will fail with an "access denied" error.

The problem occurs as Samba allows clients using the UNIX
extensions (which are also turned on by default) to create
symlinks on remotely mounted shares on which they have write
access that point to any path on the file system.

This is by design, as applications running on UNIX clients
may have good reasons to create symlinks anywhere on the
filesystem they have write access that point to local files
(such as /etc/passwd).

UNIX clients will resolve these links locally, but Windows
clients will resolve them on the server. It is this combination
that causes the problem.

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.

Would you still be vulnerable to this attack if you have wide links = 
yes but have Unix extensions set to no?


On 2/5/2010 11:17 AM, Jeremy Allison wrote:
> Claimed Zero Day exploit in Samba.
>
> A user named "kcopedarookie" posted what they claim to
> be a video of a zero-day exploit in Samba on youtube
> yesterday here:
>
> http://www.youtube.com/watch?v=NN50RtZ2N74&aia=true
>
> The video shows modifications to smbclient allowing
> /etc/passwd to be downloaded from a remote server.
>
> The issue is actually a default insecure configuration
> in Samba.
>
> Quick FAQ: What do I do !
> -------------------------
>
> Set:
>
> wide links = no
>
> in the [global] section of your smb.conf and restart
> smbd to eliminate this problem.
>
> Longer FAQ: The real issue
> --------------------------
>
> The problem comes from a combination of two features in
> Samba, each of which on their own are useful to Administrators,
> but in combination allow users to access any file on the system
> that their logged in username has permissions to read (this is
> not a privilege escalation problem).
>
> By default Samba ships with the parameter "wide links = yes",
> which allows Administrators to locally (on the server) add
> a symbolic link inside an exported share which SMB/CIFS clients
> will follow.
>
> 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.
>
> If the "wide links" parameter is set to "no", any
attempt
> to read this file will fail with an "access denied" error.
>
> The problem occurs as Samba allows clients using the UNIX
> extensions (which are also turned on by default) to create
> symlinks on remotely mounted shares on which they have write
> access that point to any path on the file system.
>
> This is by design, as applications running on UNIX clients
> may have good reasons to create symlinks anywhere on the
> filesystem they have write access that point to local files
> (such as /etc/passwd).
>
> UNIX clients will resolve these links locally, but Windows
> clients will resolve them on the server. It is this combination
> that causes the problem.
>
> 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.
-- 
C. J. Keist                     Email: cj.keist at colostate.edu
UNIX/Network Manager            Phone: 970-491-0630
Engineering Network Services    Fax:   970-491-5569
College of Engineering, CSU
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'