Linux SambaCry

Great news everyone, Windows is not the only operating system with remote code execution via SMB. Linux has also its own, seven-year-old version of the bug. /s

This Linux remote execution vulnerability (CVE-2017-7494) affects Samba, the Linux re-implementation of the SMB networking protocol, from versions 3.5.0 onwards (since 2010). The SambaCry moniker was almost unavoidable.

The bug, however, has nothing to do on how Eternalblue works, one of the exploits that the current version of WannaCry ransomware packs with. While Eternalblue is essentially a buffer overflow exploit, CVE-2017-7494 takes advantage of an arbitrary shared library load.  To exploit it, a malicious client needs to be able to upload a shared library file to a writeable share, afterwards it’s possible for the attacker to cause the server to load and execute it. A Metasploit exploit module is already public, able to target Linux ARM, X86 and X86_64 architectures.

A patch addressing this defect has been posted to the official website and Samba 4.6.4, 4.5.10 and 4.4.14 have been issued as security releases to correct the defect. Patches against older Samba versions are also available. If you can’t apply the patch at the moment, the workaround is to add the parameter “nt pipe support = no” to the [global] section of your smb.conf and restart smbd. Note that this can disable some expected functionality for Windows clients.

Meanwhile, NAS vendors start to realise they have work on their hands. Different brands and models that use Samba for file sharing (a lot, if not all, of them provide this functionality) will have to issue firmware updates if they want to patch this flaw. If the firmware updates for these appliances take the same time they usually do, we will have this bug around for quite some time.

25 thoughts on “Linux SambaCry

  1. All Debian derived distributions should have had this covered already by a recent update. I’d recommend never using Samba over more exposed networks, sshfs mounts work really well unless you need more than 100 megabytes a second transfers over your gigabit LAN (yeah bytes not bits).

    1. For some reason, when trying to mount a remote (Fedora 25) directory using sshfs, it works fine but when I try to do the same thing using fstab to do it automatically, I get connection reset by peer error message… and it used to work fine when the server was Ubuntu….

      1. sshfs can hang your x11 session if the connection is lost (-o reconnect -C -o workaround=all ), and will require the key pair for the account to be valid.

        In general even after a umount, you may need to kill the daemon prior to trying to fix the connection again:
        sudo kill -9 `ps -A | grep sshfs | awk ‘{print $1}’ `

    2. sshfs is another one that works great in theory but falls on it’s face in practice. You can tune the shit out of it per site and it will work, but as with most linuxy things, i wish someone would spend more time making it more fault tolerant rather than cutting edge.

      1. Not sure what you are doing wrong but I moved 0.7 terabytes vs sshfs the other day without a single problem, it was a huge number of files too. This was consolidating two archives down into one folder tree on a third machine. Is that real world enough for you or have you a distinctly different scenario in mind?

        1. Im not saying it works badly, but requires tweaking every time I’ve used it. I agree it would be a worse world without it, but if someone would focus on a rock solid data transfer system, they could crash their gold Ferrari into a tree and drive their silver one home.

  2. Glad to hear that recent stuff has been patched. I was leaning away from an “off the shelf, plug and play NAS” and more toward a homebrew setup based on a headless Odroid XU4 with an external 6TB drive. Now I know that this vulnerability may not be fixed by those vendors, it makes my choice easy.

    1. Depends which vendor of NAS that you’re looking at. Random Chinese tat – sure. QNAP/Synology/etc … you can expect firmware updates reasonably speedily (on supported platforms, of course)

Leave a Reply to SPURDOCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.