Developers fixed vulnerability in Samba only a year after detection

Vulnerability in Samba is fixed one year after it was found. Over the course of a year, attackers could exploit a vulnerability in Samba software as they could bypass file sharing permissions and go beyond the shared root directory.

The vulnerability contained version of Samba 4.9.0, released on September 13, 2018, and only a year later it was fixed.

“Operation is possible on systems with the” wide links “parameter enabled (determines whether symbolic links can be used in shared resources) in the Samba configuration file, as well as provided that unsafe” wide links “are allowed or the Unix extensions parameter is set to” no “, – is indicated in the Samba security service message.

Vulnerability (CVE-2019-10197) is associated with incorrect implementation of the cache reset mechanism, which tracks successful changes to the directory. If the user does not have access rights to the shared root directory, he will be denied (ACCESS_DENIED) on the first request.

Read also: Foxit Software Alerts Users About Compromise

A successful directory change will flush the cache that recorded the rejected request. If this does not happen, the next SMB request “will work in the wrong directory and not return ACCESS_DENIED”, for example, it can be the root directory of another shared resource that the client accessed earlier, or even the global root directory of the system.

This issue does not affect Unix permissions checking in the kernel. The developers assigned the vulnerability a rating of 8.7 points on the CVSS scale, while others rated it at 9.1 points.

Recommendations:

Developers have released patches that fix the vulnerability, and administrators are recommended to either apply them if they work with versions of Samba below 4.9.13 and 4.10.8, or install the latest stable releases.

If applying the fix is not possible, Samba provides the following three mitigation actions to choose from:

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.