== Subject:     Insufficient symlink verification in smbd.
== CVE ID#:     CVE-2015-5252
== Versions:    All versions of Samba, from 3.0.0 to 4.3.2
== Summary:     Insufficient symlink verification could allow
==		data access outside share path.


All versions of Samba from 3.0.0 to 4.3.2 inclusive are vulnerable to
a bug in symlink verification, which under certain circumstances could
allow client access to files outside the exported share path.

If a Samba share is configured with a path that shares a common path
prefix with another directory on the file system, the smbd daemon may
allow the client to follow a symlink pointing to a file or directory
in that other directory, even if the share parameter "wide links" is
set to "no" (the default).

For example. Given two directories on the file system:



If a Samba share is created as follows:

	path = /share
	wide links = no

Then a symlink with the path

/share/symlink -> /share1/file

would be followed by smbd, due to the fact that only the string
"/share" is checked to see if it matches the target path. This means a
path that starts with "/share", such as "/share1" will also match.

Patch Availability

Patches addressing this defect have been posted to

Additionally, Samba 4.3.3, 4.2.7 and 4.1.22 have been issued as
security releases to correct the defect.
Samba vendors and administrators running affected versions are
advised to upgrade or apply the patch as soon as possible.


Ensure all exported share paths do not share base path names with
other directories on the file system.

Please note, setting the smb.conf variable "follow symlinks = no" is
*NOT* a workaround for this problem, as this only prohibits smbd from
following a symlink at the end of a path.

A symlink could be created that points to the directory which shares a
base path name instead, and smbd would still follow that link. For
example, with the above share definition, given a symlink of:

/share/symlink -> /share1

a client could send a relative path such as "symlink/file", which
would still be followed by smbd as the end component "file" of
"symlink/file" is *NOT* a symlink, and so is not affected by "follow
symlinks = no".


The problem was found by Jan "Yenya" Kasprzak and the Computer Systems
Unit team at Faculty of Informatics, Masaryk University. The fix was
created by Jeremy Allison of Google.