=========================================================== == 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. == =========================================================== =========== Description =========== 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. ================== Patch Availability ================== Patches addressing this defect have been posted to https://www.samba.org/samba/history/security.html 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. =========== Workarounds =========== 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". ======= Credits ======= 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.