Samba - Loading shared modules from any path in the system leading to Remote Code Execution. - CVE-2017-7494

Red Hat Product Security has been made aware of a vulnerability affecting samba.  The vulnerability has been assigned CVE-2017-7494 This issue was publicly disclosed on May 24th, 2017 and has been rated as Important.

Samba is vulnerable to a remote code execution flaw. A remote malicious client which has write access to a samba share could upload a shared library and cause the samba server to execute it, this could result in code execution as root user. 

Background Information

In Samba 3.5 and above, a remote attacker with write privileges to a samba share could gain remote code execution as root. Also a non privileged user having shell access to a samba server could escalate his priviledges to gain root access.

Note: SELinux is enabled by default and our default policy prevents loading of modules from outside of samba's module directories and therefore blocks the exploit.

References:
https://www.samba.org/samba/security/CVE-2017-7494.html

Acknowledgement

Red Hat would like to thanks the Samba project for reporting this flaw. Upstream acknowleges steelo as the original reporter of this flaw.

Red Hat Product Security has rated this update as having a security impact of Important. This flaw affects the version of 'samba' package shipped with Red Hat Enterprise Linux 6 and 7 and Red Hat Gluster Storage 3; the version of 'samba3x' shipped with Red Hat Enterprise Linux 5; lastly the version of 'samba4' shipped with Red Hat Enterprise Linux 6. This flaw does not affect the version of 'samba' shipped with Red Hat Enterprise Linux 5. Details of a mitigation is listed under the Resolve tab of this article.

Impacted Products

The following Red Hat product versions are impacted:

• Red Hat Enterprise Linux 5
• Red Hat Enterprise Linux 6 
• Red Hat Enterprise Linux 7
• Red Hat Gluster Storage 3.2

Take Action

All Red Hat customers running affected versions of samba are strongly recommended to update as soon as patches are available. Details about impacted packages as well as recommended mitigation are noted below. 

Updates for Affected Products

*An active ELS subscription is required for access to this patch.

Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

Mitigation

SELinux is enabled by default on Red Hat Enterprise Linux  and the default policy prevents loading of modules from outside of samba's module directories and therefore blocks this exploit.  System Administrators could also mount the filessytem which is used by samba for its writeable share, using "noexec" option.

System Administrators could also follow this alternate mitigation:

1) Mount the filesystem being used for this writable samba share with the noexec option. This prevents the exploit from being executed on the samba server.

Add the option:

nt pipe support = no

into the [global] section of your smb.conf and restart smbd. This prevents clients from accessing any named pipe endpoints. Note this can disable some expected functionality for clients connecting to Samba. Especially if you're running Samba as a PDC (NT4 domain controller) it will stop working.

How to check if the mitigation has been applied:

A. Before applying the above mitigation:

# rpcclient ncacn_np:<samba server name> -c 'getusername' -UAdministrator%<Admin password> -d

Output:

Account Name: Administrator, Authority Name: DOMAIN

B. After applying the above mitigation,  output:

could not initialise lsa pipe. Error was NT_STATUS_ACCESS_DENIED
could not obtain sid for domain PLUTO
error: NT_STATUS_ACCESS_DENIED

Ansible Playbook

An Ansible  playbook is available.  This playbook will apply a mitigation for this issue by disabling `nt pipe support` in the Samba configuration file. It will then reload the Samba service. Please note that this process will start the service even if it wasn't running before, so note the state of the service before and after you run this playbook to ensure it is in the desired state.

To run the playbook, specify the names of the hosts or groups you wish to address in the HOSTS variable, like so:
# ansible-playbook mitigation.yml -e HOSTS=dbserver,webserver