A vulnerability involving a Linux package called Samba is making the rounds, and in the spirit of the Windows-based exploit known as WannaCry, this one is called SambaCry. Red Hat Enterprise Linux systems from version 5 to 7 may likely be exploitable by this threat. Red Hat covers the topic via these security advisories (which basically urge updating):
- Red Hat Enterprise Linux 5 ELS [RHSA-2017:1272](http://rhn.redhat.com/errata/RHSA-2017-1272.html)
- Red Hat Enterprise Linux 6 [RHSA-2017:1271](http://rhn.redhat.com/errata/RHSA-2017-1271.html)
- Red Hat Enterprise Linux 7 [RHSA-2017:1270](http://rhn.redhat.com/errata/RHSA-2017-1270.html)
All Samba versions from 3.5.0 up to 4.6.5 except for 4.4.14, 4.5.10 and 4.6.4 are vulnerable to SambaCry, unless SELinux security controls — which are basically like application firewalls — are in use to secure the target system. Fortunately, the default SELinux policy prevents the loading of outside modules not in Samba’s module directories so the exploit cannot be triggered.
Unlike WannaCry, SambaCry is a remote code execution vulnerability, not ransomware. If exploited, another system could upload code to a writable Samba share then run it with root privileges to execute the code via the smdbd process, possibly compromising or infecting the target server. It does require being able to utilize authentication credentials against the target system, but if passwords are weak or nonexistent, this can be easily accomplished.
Samba updates are available from Red Hat via their Satellite and Subscription Management solutions which provide centralized patch management options. Assuming your Red Hat systems are subscribed to these services (or you have a home-grown method for using yum repositories to release patches to systems), the Samba update should be available if not already deployed (I highly recommend checking the status of this update via your management console). If you are rolling your own patches and updates you can get the latest secure version of Samba (4.6.5) here.
You probably have a regular schedule for installations and may be able to schedule this update install from a centralized point of management if it is not present on your systems. However, if you’re working off manual updating, not all systems are checked into a patch management solution or you otherwise need a hands-on update methodology you can follow the processes below once you’ve ensured the Samba update is present in your yum repository.
If your server is GUI-based, access System / Administration / Software Update (or run the gpk-update-viewer command) then install the update via the resulting window.
That’s tedious, however, so I advise updating Samba via the command line:
1.Type yum makecache (this downloads all recent metadata for your yum repositories).
2.Type yum update (or yum update samba to only update samba).
3.Confirm the update(s) complete successfully.
3.Type service smbd restart to restart the smbd service.
4.Type yum info samba to verify the currently-installed version of Samba.
Obviously it wouldn’t make sense to run this command manually on multiple systems, so you could put together a simple bash script that utilizes a “for loop.” Place all your server hostnames in a file (servers.txt for instance) then create a script file containing the following:
for l in `cat servers.txt`; do ssh -q $l yum makecache; done
for l in `cat servers.txt`; do ssh -q $l yum update samba; done
for l in `cat servers.txt`; do ssh -q $l yum service smdb restart; done
for l in `cat servers.txt`; do ssh -q $l yum info samba; done
(note that “for l” represents “for l as in the lower case letter l”).
Make the script file executable (chmod +x) then fire it off and your systems should be in good shape.
It’s also possible to mitigate the threat via a manual basis if you can’t patch your systems for some reason. This involves mounting the Samba share file system in use with the “noexec” option to block the exploit.
To do so:
1.Edit the smb.conf file and look for the [global] section.
2.Add the parameter: ~~~ nt pipe support = no ~~~3.Save the file.
4. Restart the Samba service (service smbd restart).
Note that this may impact or disable access or other functions utilized by Windows clients so be sure to test before deploying in a production environment.
Of course, you can also use a for loop to scp the file to your target systems (usually under /etc/samba/smb.conf) and restart the Samba service on all your servers if need be. As previously described, place all your server hostnames in a file (servers.txt for instance), ensure the smb.conf file has been updated (let’s assume it’s in /etc/samba/smb.conf) then create a script file containing the following:
for l in `cat servers.txt`; do scp /etc/samba/smb.conf $l:/etc/samba; done
for l in `cat servers.txt`; do ssh -q $l service smdb restart; done
Make the script file executable (chmod +x) before running it, of course.
Another mitigation method involves implementing segregated networks, something of which I am a huge fan from an organizational and security standpoint. If your Samba servers are on a separate network from potential threats and traffic between the two networks is being blocked, SambaCry cannot be leveraged. Of course, this may not be an overnight solution but it bears consideration for the future as it can certainly help protect against the vulnerabilities which around bound to be discovered down the road.
For more tips on dealing with SambaCry, check out this other article from TechRepublic: How to protect Samba from the SambaCry exploit