As per upstream advisory: On a Samba SMB server for all versions of Samba from 4.9.0 clients are able to escape outside the share root directory if certain configuration parameters set in the smb.conf file. The problem is reproducable if the 'wide links' option is explicitly set to 'yes' and either 'unix extensions = no' or 'allow insecure wide links = yes' is set in addition. If a client has no permissions to enter the share root directory it will get ACCESS_DENIED on the first request. However smbd has a cache that remembers if it successfully changed to a directory. This cache was not being reset on failure. The following SMB request will then silently operate in the wrong directory instead of returning ACCESS_DENIED. That directory is either the share root directory of a different share the client was operating on successfully before or the global root directory ('/') of the system. The unix token (uid, gid, list of groups) is always correctly impersonated before each operation, so the client is still restricted by the unix permissions enfored by the kernel.
Acknowledgments: Name: Stefan Metzmacher (SerNet)
Mitigation: The following methods can be used as a mitigation (only one is needed): 1. Use the 'sharesec' tool to configure a security descriptor for the share that's at least as strict as the permissions on the share root directory. 2. Use the 'valid users' option to allow only users/groups which are able to enter the share root directory. 3. Remove 'wide links = yes' if it's not really needed. 4. In some situations it might be an option to use 'chmod a+x' on the share root directory, but you need to make sure that files and subdirectories are protected by stricter permissions. You may also want to 'chmod a-w' in order to prevent new top level files and directories, which may have less restrictive permissions.
Note: Only the following configurations are affected: If the 'wide links' option is explicitly set to 'yes' and either 'unix extensions = no' or 'allow insecure wide links = yes' is set in addition. Also the attack is restricted by usual Linux DAC permissions e.g. file permissions on the resource. Further selinux permissions may also restrict the ability of the attacker to view/change files outside the usual share path.
Statement: Only samba configurations where 'wide links' option is explicitly set to 'yes' is affected by this flaw. Therefore default configurations of samba package shipped with Red Hat Products are not affected. This vulnerability exists in the samba server, client side packages are not affected.
External References: https://www.samba.org/samba/security/CVE-2019-10197.html
Created samba tracking bugs for this issue: Affects: fedora-all [bug 1748308]
This issue has been addressed in the following products: Red Hat Gluster Storage 3.5 for RHEL 7 Via RHSA-2019:3253 https://access.redhat.com/errata/RHSA-2019:3253
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-10197
This issue has been addressed in the following products: Red Hat Gluster Storage 3.5 for RHEL 6 Via RHSA-2019:4023 https://access.redhat.com/errata/RHSA-2019:4023
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:1084 https://access.redhat.com/errata/RHSA-2020:1084
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1878 https://access.redhat.com/errata/RHSA-2020:1878