Samba has long been the standard for providing shared file and print services to Windows clients on *nix systems. Used by home users, mid-size businesses, and large companies alike, it stands out as the go-to solution in environments where different operating systems coexist.
As it sadly happens with broadly-used tools, most Samba installations are under risk of an attack that may exploit a known vulnerability, which was not considered to be serious until the WannaCry ransomware attack hit the news not too long ago.
In this article, we will explain what this Samba vulnerability is and how to protect the systems you are responsible for against it. Depending on your installation type (from repositories or from source), you will need to take a different approach to do it.
If you are currently using Samba in any environment or know someone who does, read on!
Outdated and unpatched systems are vulnerable to a remote code execution vulnerability. In simple terms, this means that a person with access to a writeable share can upload a piece of arbitrary code and execute it with root permissions in the server.
The issue is described in the Samba website as CVE-2017-7494 and is known to affect Samba versions 3.5 (released in early March 2010) and onwards. Unofficially, it has been named SambaCry due to its similarities with WannaCry: both target the SMB protocol and are potentially wormable – which can cause it to spread from system to system.
Debian, Ubuntu, CentOS and Red Hat have taken rapid action to protect its users and have released patches for their supported versions. Additionally, security workarounds have also been provided for unsupported ones.
As mentioned earlier, there are two approaches to follow depending on the previous installation method:
If you installed Samba from your distribution’s repositories.
Let’s take a look at what you need to do in this case:
Fix Sambacry in Debian
Make sure apt is set to get the latest security updates by adding the following lines to your sources list (/etc/apt/sources.list):
deb http://security.debian.org stable/updates main deb-src http://security.debian.org/ stable/updates main
Next, update the list of available packages:
# aptitude update
Finally, make sure the version of the samba package matches the version where the vulnerability has been fixed (see CVE-2017-7494):
# aptitude show samba
Fix Sambacry in Ubuntu
To begin, check for new available packages and update the samba package as follows:
$ sudo apt-get update $ sudo apt-get install samba
The Samba versions where the fix for CVE-2017-7494 has already been applied are the following:
- 17.04: samba 2:4.5.8+dfsg-0ubuntu0.17.04.2
- 16.10: samba 2:4.4.5+dfsg-2ubuntu5.6
- 16.04 LTS: samba 2:4.3.11+dfsg-0ubuntu0.16.04.7
- 14.04 LTS: samba 2:4.3.11+dfsg-0ubuntu0.14.04.8
Finally, run the following command to verify that your Ubuntu box now has the right Samba version installed.
$ sudo apt-cache show samba
Fix Sambacry on CentOS/RHEL 7
The patched Samba version in EL 7 is samba-4.4.4-14.el7_3. To install it, do
# yum makecache fast # yum update samba
As before, make sure you have now the patched Samba version:
# yum info samba
Older, still supported versions of CentOS and RHEL have available fixes as well. Check RHSA-2017-1270 to find out more.
If you installed Samba from source
Note: The following procedure assumes that you have previously built Samba from source. You are highly encouraged to try it out extensively in a testing environment BEFORE deploying it to a production server.
Additionally, make sure you back up the smb.conf file before you start.
In this case, we will compile and update Samba from source as well. Before we begin, however, we must ensure all the dependencies are previously installed. Note that this may take several minutes.
In Debian and Ubuntu:
# aptitude install acl attr autoconf bison build-essential \ debhelper dnsutils docbook-xml docbook-xsl flex gdb krb5-user \ libacl1-dev libaio-dev libattr1-dev libblkid-dev libbsd-dev \ libcap-dev libcups2-dev libgnutls28-dev libjson-perl \ libldap2-dev libncurses5-dev libpam0g-dev libparse-yapp-perl \ libpopt-dev libreadline-dev perl perl-modules pkg-config \ python-all-dev python-dev python-dnspython python-crypto xsltproc \ zlib1g-dev libsystemd-dev libgpgme11-dev python-gpgme python-m2crypto
In CentOS 7 or similar:
# yum install attr bind-utils docbook-style-xsl gcc gdb krb5-workstation \ libsemanage-python libxslt perl perl-ExtUtils-MakeMaker \ perl-Parse-Yapp perl-Test-Base pkgconfig policycoreutils-python \ python-crypto gnutls-devel libattr-devel keyutils-libs-devel \ libacl-devel libaio-devel libblkid-devel libxml2-devel openldap-devel \ pam-devel popt-devel python-devel readline-devel zlib-devel
Stop the service:
# systemctl stop smbd
Download and untar the source (with 4.6.4 being the latest version at the time of this writing):
# wget https://www.samba.org/samba/ftp/samba-latest.tar.gz # tar xzf samba-latest.tar.gz # cd samba-4.6.4
For informative purposes only, check the available configure options for the current release with.
# ./configure --help
You may include some of the options returned by the above command if they were used in the previous build, or you may choose to go with the default:
# ./configure # make # make install
Finally, restart the service.
# systemctl restart smbd
and verify you’re running the updated version:
# smbstatus --version
which should return 4.6.4.
If you are running an unsupported version of a given distribution and are unable to upgrade to a more recent one for some reason, you may want to take the following suggestions into account:
- If SELinux is enabled, you are protected!
- Make sure Samba shares are mounted with the noexec option. This will prevent the execution of binaries residing on the mounted filesystem.
nt pipe support = no
to the [global] section of your smb.conf file and restart the service. You may want to keep in mind that this “may disable some functionality in Windows clients”, as per the Samba project.
Important: Be aware that the option “nt pipe support = no” would disable shares listing from Windows clients. Eg: When you type \\10.100.10.2\ from Windows Explorer on a samba server you would get a permission denied. Windows clients would have to manually specify the share as \\10.100.10.2\share_name to access the share.
In this article, we have described the vulnerability known as SambaCry and how to mitigate it. We hope that you will be able to use this information to protect the systems you’re responsible for.
If you have any questions or comments about this article, feel free to use the form below to let us know.