According to a rapid7 article there are some vulnerable Samba versions allowing a remote code execution on Linux systems:

While the WannaCry ransomworm impacted Windows systems and was easily identifiable, with clear remediation steps, the Samba vulnerability will impact Linux and Unix systems and could present significant technical obstacles to obtaining or deploying appropriate remediations.


All versions of Samba from 3.5.0 onwards are vulnerable to a remote code execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it.

Possible attack scenario:

Starting from the two factors:

  • The Samba vulnerability isn't fixed yet on some Linux distributions.
  • There is a non-patched local privilege escalation vulnerability on some Linux kernel versions (for example, CVE-2017-7308 on the 4.8.0-41-generic Ubuntu kernel).

An attacker can access a Linux machine and elevate privileges using a local exploit vulnerability to gain the root access and installing a possible future ramsomware, similar to this mock up WannaCry ransomware for Linux.


A newest article "Warning! Hackers Started Using "SambaCry Flaw" to Hack Linux Systems" demonstrate how to use the Sambacry flaw to infecte a linux machine.

The prediction came out to be quite accurate, as honeypots set up by the team of researchers from Kaspersky Lab have captured a malware campaign that is exploiting SambaCry vulnerability to infect Linux computers with cryptocurrency mining software.

Another security researcher, Omri Ben Bassat‏, independently discovered the same campaign and named it "EternalMiner" .

According to the researchers, an unknown group of hackers has started hijacking Linux PCs just a week after the Samba flaw was disclosed publicly and installing an upgraded version of "CPUminer," a cryptocurrency mining software that mines "Monero" digital currency.

After compromising the vulnerable machines using SambaCry vulnerability, attackers execute two payloads on the targeted systems:

INAebsGB.so — A reverse-shell that provides remote access to the attackers.

cblRWuoCc.so — A backdoor that includes cryptocurrency mining utilities – CPUminer.

TrendLab report posted on July 18, 2017: Linux Users Urged to Update as a New Threat Exploits SambaCry

How do I secure a Linux system to prevent being attacked?

  • 23
    WannaCry is Windows malware. A unix virus could be written exploiting this unrelated problem with this unrelated implementation of the same protocol, but this has nothing to do with the windows malware. This link you give to WannaCry for Linux is a hoax, from skimming the source it looks like the output from some graphical "make your own gui"-software, without any actual program but a GUI which does nothing.
    – Nobody
    May 25, 2017 at 15:41
  • 2
    @GAD3R using my iPhone with Google Translate / camera mode the comments in Chinese say indeed the source is not complete. I would advise reworking the question around the CVE, deleting the github link and not about ransomware that still does not exist; or if you still want to work around that idea, making it explicit the github link is just a mock up of that idea May 25, 2017 at 17:54
  • 8
    @GAD3R Yeah, if someone can access my system remotely with high privileges, it's much less of a pain to just use native Linux utilities to encrypt my hard drive, and write a QT GUI like that in the hoax. All the actual features (i.e. spreading) of WannaCry depend on Windows exploits. Mentioning "WannaCry" is click-baiting, pure and simple.
    – Nobody
    May 25, 2017 at 18:31
  • 7
    @Nobody To be fair enough, I believe the OP is in good faith and not aware of it being just a GUI; we are not Chinese natives to read the comments and as he himself says, he is not very versed into reading source code; IMO the parallels between the two vulnerabilities, giving the timings are also appropriate. Give it some slack. Nonetheless, the implications of the CVE itself are worrisome. May 25, 2017 at 18:42
  • 3
    IMO I would not recommend closing the question, if someone has a different idea, go ahead. I have reworked the question text for it not to mention a ransomware that has not yet been made. The workaround that I mention was at least useful in a legacy system we still have. May 25, 2017 at 18:52

2 Answers 2


This Samba new vulnerability is already being called "Sambacry", while the exploit itself mentions "Eternal Red Samba", announced in twitter (sensationally) as:

Samba bug, the metasploit one-liner to trigger is just: simple.create_pipe("/path/to/target.so")

Potentially affected Samba versions are from Samba 3.5.0 to 4.5.4/4.5.10/4.4.14.

If your Samba installation meets the configurations described bellow, the fix/upgrade should be done ASAP as there are already exploits, other exploit in python and metasploit modules out there.

More interestingly enough, there are already add-ons to a know honeypot from the honeynet project, dionaea both to WannaCry and SambaCry plug-ins.

Samba cry seems to be already being (ab)used to install more crypto-miners "EternalMiner" or double down as a malware dropper in the future.

honeypots set up by the team of researchers from Kaspersky Lab have captured a malware campaign that is exploiting SambaCry vulnerability to infect Linux computers with cryptocurrency mining software. Another security researcher, Omri Ben Bassat‏, independently discovered the same campaign and named it "EternalMiner."

The advised workaround for systems with Samba installed (which also is present in the CVE notice) before updating it, is adding to smb.conf:

nt pipe support = no

(and restarting the Samba service)

This is supposed to disable a setting that turns on/off the ability to make anonymous connections to the windows IPC named pipes service. From man samba:

This global option is used by developers to allow or disallow Windows NT/2000/XP clients the ability to make connections to NT-specific SMB IPC$ pipes. As a user, you should never need to override the default.

However from our internal experience, it seems the fix is not compatible with older? Windows versions ( at least some? Windows 7 clients seem to not work with the nt pipe support = no), and as such the remediation route can go in extreme cases into installing or even compiling Samba.

More specifically, this fix disable shares listing from Windows clients, and if applied they have to manually specify the full path of the share to be able to use it.

Other known workaround is to make sure Samba shares are mounted with the noexec option. This will prevent the execution of binaries residing on the mounted filesystem.

The official security source code patch is here from the samba.org security page.

Debian already pushed yesterday (24/5) an update out the door, and the corresponding security notice DSA-3860-1 samba

To verify in if the vulnerability is corrected in Centos/RHEL/Fedora and derivates, do:

#rpm -q –changelog samba | grep -i CVE
– resolves: #1450782 – Fix CVE-2017-7494
– resolves: #1405356 – CVE-2016-2125 CVE-2016-2126
– related: #1322687 – Update CVE patchset

There is now an nmap detection script :samba-vuln-cve-2017-7494.nse for detecting Samba versions, or a much better nmap script that checks if the service is vulnerable at http://seclists.org/nmap-dev/2017/q2/att-110/samba-vuln-cve-2017-7494.nse , copy it to /usr/share/nmap/scripts and then update the nmap database , or run it as follows:

nmap --script /path/to/samba-vuln-cve-2017-7494.nse -p 445 <target>

About long term measures to protect the SAMBA service: The SMB protocol should never be offered directly to the Internet at large.

It goes also without saying that SMB has always been a convoluted protocol, and that these kind of services ought to be firewalled and restricted to the internal networks [to which they are being served].

When remote access is needed, either to home or specially to corporate networks, those accesses should be better done using VPN technology.

As usual, on this situations the Unix principle of only installing and activating the minimum services required does pay off.

Taken from the exploit itself:

Eternal Red Samba Exploit -- CVE-2017-7494.
Causes vulnerable Samba server to load a shared library in root context.
Credentials are not required if the server has a guest account.
For remote exploit you must have write permissions to at least one share.
Eternal Red will scan the Samba server for shares it can write to. It will also determine the fullpath of the remote share.

    For local exploit provide the full path to your shared library to load.  

    Your shared library should look something like this

    extern bool change_to_root_user(void);
    int samba_init_module(void)
        /* Do what thou wilt */

It is also known systems with SELinux enabled are not vulnerable to the exploit.

See 7-Year-Old Samba Flaw Lets Hackers Access Thousands of Linux PCs Remotely

According to the Shodan computer search engine, more than 485,000 Samba-enabled computers exposed port 445 on the Internet, and according to researchers at Rapid7, more than 104,000 internet-exposed endpoints appeared to be running vulnerable versions of Samba, out of which 92,000 are running unsupported versions of Samba.

Since Samba is the SMB protocol implemented on Linux and UNIX systems, so some experts are saying it is "Linux version of EternalBlue," used by the WannaCry ransomware.

...or should I say SambaCry?

Keeping in mind the number of vulnerable systems and ease of exploiting this vulnerability, the Samba flaw could be exploited at large scale with wormable capabilities.

Home networks with network-attached storage (NAS) devices [that also run Linux] could also be vulnerable to this flaw.

See also A wormable code-execution bug has lurked in Samba for 7 years. Patch now!

The seven-year-old flaw, indexed as CVE-2017-7494, can be reliably exploited with just one line of code to execute malicious code, as long as a few conditions are met. Those requirements include vulnerable computers that:

(a) make file- and printer-sharing port 445 reachable on the Internet,
(b) configure shared files to have write privileges, and
(c) use known or guessable server paths for those files.

When those conditions are satisfied, remote attackers can upload any code of their choosing and cause the server to execute it, possibly with unfettered root privileges, depending on the vulnerable platform.

Given the ease and reliability of exploits, this hole is worth plugging as soon as possible. It's likely only a matter of time until attackers begin actively targeting it.

Also Rapid 7 - Patching CVE-2017-7494 in Samba: It’s the Circle of Life

And more SambaCry: The Linux Sequel to WannaCry.

Need-to-Know Facts

CVE-2017-7494 has a CVSS Score of 7.5 (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)3.

Threat Scope

A shodan.io query of "port:445 !os:windows" shows approximately one million non-Windows hosts that have tcp/445 open to the Internet, more than half of which exist in the United Arab Emirates (36%) and the U.S. (16%). While many of these may be running patched versions, have SELinux protections, or otherwise don't match the necessary criteria for running the exploit, the possible attack surface for this vulnerability is large.

P.S. The commit fix in the SAMBA github project appear to be commit 02a76d86db0cbe79fcaf1a500630e24d961fa149

  • 2
    You are welcome. I would add that in my time zone, I acted on the Debian security notice yesterday around 9AM May 25, 2017 at 11:23
  • 6
    Unlike in Windows though, Samba isn't on by default in most Linux distros right?
    – raphael
    May 25, 2017 at 20:29
  • 1
    @raphael Indeed, but if I received a penny for every server I found with the full set of core DVDs installed...I have edited slightly the answer to address that idea. May 25, 2017 at 20:57
  • 10
    As far as I can tell that nmap script just checks the version of samba, not if you're vulnerable. AFAICT, to exploit the vulnerability, one needs to be able to upload files to the server. So the vulnerability is nowhere as serious as the Eternalblue Windows one. If you allow uploading files over the internet without authentication, you have a problem whether samba is vulnerable or not. May 26, 2017 at 13:51
  • 1
    @StéphaneChazelas thanks, I have had not yet time to check the script May 26, 2017 at 14:36

Most of us running Samba servers out there are probably running it inside LANs, behind firewalls and don't expose its ports directly to the outside world.

It would an awful practice if you did so, and inexcusable one when there are simple, effective and free (as in beer and as in speech) VPN solutions like OpenVPN around. SMB was not designed with open Internet in mind (heck, TCP/IP even came as an afterthought in that protocol) and should be treated as such. Additional suggestion is running firewall rules on the actual file sharing host that whitelist only local (and eventually VPN) network adresses on all SMB ports (139/TCP, 445/TCP, 137/UDP and 138/UDP).

Also, if your use case allows, you should consider running Samba unprivileged (as, say, samba user who is not alias of root). I understand that it's not that easy to marry limitations of NT ACLs with POSIX ACLs with this setup but if it's possible to do so in your particular setup it's the way to go.

Finally, even with such a "lockdown" it's still advisable to apply a patch if you can (because there are NAS boxes out there where that might not be doable), and to test if your particular use case works with nt pipe support set to no.

  • 4
    “It's only accessible on the intranet” is probably what some of the admins in companies where WannaCry spread thought.
    – Carsten S
    May 29, 2017 at 8:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .