=========================================================== == Subject: Information leak via symlinks of existance of == files or directories outside of the exported == share. == == CVE ID#: CVE-2021-44141 == == == Versions: All versions of the Samba file server prior to == 4.15.x, 4.14.x, 4.13.x == == Summary: A client can use a symlink to discover if a named == or directory exists on the filesystem outside of == the exported share. The user must have permissions == to query a symlink inside the exported share using == SMB1 with unix extensions turned on. =========================================================== =========== Description =========== All versions of Samba prior to 4.15.x, 4.14.x, 4.13.x are vulnerable to a malicious client using a server symlink to determine if a file or directory exists in an area of the server file system not exported under the share definition. SMB1 with unix extensions has to be enabled in order for this attack to succeed. Clients that have write access to the exported part of the file system under a share via SMB1 unix extensions or via NFS can create symlinks that point to arbitrary files or directories on the server filesystem. Clients can then use SMB1 unix extension information queries to determine if the target of the symlink exists or not by examining error codes returned from the smbd server. There is no ability to access these files or directories, only to determine if they exist or not. If SMB1 is turned off and only SMB2 is used, or unix extensions are not enabled then there is no way to discover if a symlink points to a valid target or not via SMB2. For this reason, even if symlinks are created via NFS, if the Samba server does not allow SMB1 with unix extensions there is no way to exploit this bug. Finding out what files or directories exist on a file server can help attackers guess system user names or the exact operating system release and applications running on the server hosting Samba which may help mount further attacks. SMB1 has been disabled on Samba since version 4.11.0 and onwards. Exploitation of this bug has not been seen in the wild. ================== Patch Availability ================== Patches addressing this issue has been posted to: https://www.samba.org/samba/security/ Samba versions 4.15.x, 4.14.x, 4.13.x have been issued as security releases to correct the defect. Samba administrators are advised to upgrade to this release as soon as possible. ================== CVSSv3.1 calculation ================== CVSS:AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N/E:P/RL:O/RC:C/CR:L/IR:L/AR:L/MAV:N/MAC:L/MPR:L/MUI:N/MS:U/MC:H/MI:N/MA:N base score of 4.2 ================================= Workaround and mitigating factors ================================= Do not enable SMB1 (please note SMB1 is disabled by default in Samba from version 4.11.0 and onwards). This prevents the creation or querying of symbolic links via SMB1. If SMB1 must be enabled for backwards compatibility then add the parameter: unix extensions = no to the [global] section of your smb.conf and restart smbd. This prevents SMB1 clients from creating or reading symlinks on the exported file system. However, if the same region of the file system is also exported allowing write access via NFS, NFS clients can create symlinks that allow SMB1 with unix extensions clients to discover the existance of the NFS created symlink targets. For non-patched versions of Samba we recommend only exporting areas of the file system by either SMB2 or NFS, not both. ======= Credits ======= Reported by Stefan Behrens of Jeremy Allison of Google and the Samba Team provided the fix. ========================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ==========================================================