Bug 1746225 (CVE-2019-10197)

Summary: CVE-2019-10197 samba: Combination of parameters and permissions can allow user to escape from the share path definition
Product: [Other] Security Response Reporter: Huzaifa S. Sidhpurwala <huzaifas>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: abokovoy, anoopcs, asn, dblechte, dchong, dfediuck, eedri, gdeschner, iboukris, jrivera, jstephen, lmohanty, madam, mgoldboi, michal.skrivanek, puebele, rhs-smb, sadas, sbonazzo, sbose, security-response-team, sherold, sisharma, ssorce, vbellur, yturgema
Target Milestone: ---Keywords: Reopened, Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: samba 4.9.13, samba 4.10.8, samba 4.11.0rc3 Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in samba when certain parameters were set in the samba configuration file. An unauthenticated attacker could use this flaw to escape the shared directory and access the contents of directories outside of the share.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-15 12:51:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1746240, 1746241, 1746244, 1748308, 1772808    
Bug Blocks: 1746226    

Description Huzaifa S. Sidhpurwala 2019-08-28 02:33:14 UTC
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.

Comment 1 Huzaifa S. Sidhpurwala 2019-08-28 02:33:21 UTC
Acknowledgments:

Name: Stefan Metzmacher (SerNet)

Comment 2 Huzaifa S. Sidhpurwala 2019-08-28 02:45:19 UTC
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.

Comment 3 Huzaifa S. Sidhpurwala 2019-08-28 02:50:00 UTC
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.

Comment 7 Doran Moppert 2019-08-28 05:33:13 UTC
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.

Comment 8 Doran Moppert 2019-08-29 05:01:07 UTC
External References:

https://www.samba.org/samba/security/CVE-2019-10197.html

Comment 9 Siddharth Sharma 2019-09-03 10:54:22 UTC
Created samba tracking bugs for this issue:

Affects: fedora-all [bug 1748308]

Comment 10 errata-xmlrpc 2019-10-30 12:18:26 UTC
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

Comment 11 Product Security DevOps Team 2019-10-30 12:51:15 UTC
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

Comment 14 Product Security DevOps Team 2019-11-15 12:51:12 UTC
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

Comment 15 errata-xmlrpc 2019-12-02 07:00:13 UTC
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

Comment 16 errata-xmlrpc 2020-03-31 19:21:29 UTC
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

Comment 17 errata-xmlrpc 2020-04-28 16:03:03 UTC
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