As per samba upstream advisory:


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:

/share/

/share1/

If a Samba share is created as follows:

[sharename]
        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.

The following mitigation was suggested by upstream:

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