An access flaw was found in the way Samba verified symbolic links when creating new files on a Samba share. A remote attacker could exploit this flaw to gain access to files outside of Samba's share path.
DescriptionHuzaifa S. Sidhpurwala
2015-12-10 05:01:50 UTC
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".
Comment 1Huzaifa S. Sidhpurwala
2015-12-10 06:32:25 UTC
Acknowledgements:
Red Hat would like to thank the Samba project for reporting this issue. Upstream acknowledges Jan "Yenya" Kasprzak and the Computer Systems Unit team at Faculty of Informatics, Masaryk University as the original reporters.
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".