CVE-2017-7494 - SAMBA vulnerability - Immediate mitigation and bugfix status

SUSE bugfix status

Mitigation steps at the bottom of this RHEL bulletin if you can’t risk waiting for the bugfix

Remember that Wannacry ransomware in Windows these past 3 months or so, which have paralyzed a number of major systems most notably the UK Healthcare system?

Although the vulnerability is different, the exploits which are already in the wild are the same… ransomware encrypting your shared files through a SAMBA vulnerability. Anyone running any modern version of SAMBA (3.5 and later) is affected.

At the moment as this is being posted, there are only a few infections, but if you can’t wait for the bugfix, be sure to implement the patch in the RHEL bulletin. Since this is now hitting the general public news outlets, there may be more exploits written.

And, this means that everyone should be on the watch for the expected System Update which will include this patch… Don’t delay your next system update (maybe execute daily for now).


samba-4.2.4-33.1.x86_64 for 42.1 and samba-4.4.2-11.9.1.x86_64 for 42.2 contain the fix for this particular CVE.

* Wed May 24 2017 Fix authenticated remote code execution bug;
  CVE-2017-7494; (bso#12780); (bsc#1038231).

They are both now available in the Update repository.

That being said, this vulnerability requires guest account write permissions to a public share or a user with said permissions and isn’t quite as automated as the Windows version which required no access to shares.


For SLES12 the updated Samba version is: 4.4.2-38.6.1

But I don’t know that the difference is that significant unless SAMBA shares are deployed read-only. I would think that most deployments allow Users to write to a share.

Thx for the update info, Everyone should be running “zypper up” or “zypper patch” on their machines ASAP (assuming your repo mirror has the patch already)


I assume this “Everyone” is restricted to those using Samba.
And is this for the server or for the client or for both?

It’s a flaw with the server component but the client binary will also get an up to match the version number (they’re built from the same sources after all).

Server only, client unaffected.
Server SAMBA shares are writable (any level of authentication)

Is incredibly easy to exploit.
Only possible slight complication is that the attacker generally needs to know the system path to the Share, which might be based on a fixed or variable PATH configuration.
I’ve reviewed a simple test generating output using a standard metasploit framework tool and another that doesn’t just output text but deploys a root console (executable on the Server).


I try to assess the importance of the patch (for the benefit of those who think they have to panic ;)). For a mere version number, I would not plan an extra update window.

And the message was “Everybody”, which I guess is exaggerated.

As I see it, only those system managers that are responsible for a Samba server have reason to act quickly.

I think that I first saw the update on Tuesday. I applied it to my laptop. But I did not apply to my desktop until this morning. (The desktop is a samba server). It did not seem urgent enough, so I waited until my scheduled update period.

One reason that I wasn’t seriously concerned, is that I do routinely backup the samba shares (“rsync” backup to another box).

I would say that at this time, the chance of being exploited is extremely low.

The consequences can be catastrophic, even to possibly putting out of business overnight, or facing losing your prized archive of family and/or financial files forever (You never know if even paying the ransom and applying the key will work).

Even restoring from backup of course means losing file changes since that backup.

The point is, if the patch is available and easy to apply, your worst nightmares can be avoided painlessly.


Yes, the latter advice about backup snapshots is an important strategy for protecting any important data.