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.
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).
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….
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}'
Sorry I can’t help you with RH stuff I’ve not built anything with it in the last 17 years.
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.
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?
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.
it is slower than
https://upload.wikimedia.org/wikipedia/en/thumb/1/14/Ralph_Wiggum.png/200px-Ralph_Wiggum.png
rsync (with no compression) over ssh is about 3 times faster on the same setup for new file backups.
there’s a hpn patch for openssh. it maxes out the wire speed if both cpus are fast enough… 114 mb/s over a 1gb line.
who doesn’t like fast file transfer?
WINS/SMB is a prime example of an overengineered protocol.
and ancient; originating in IBM circa 1983. But, hey, way better than NFS in my experience (admittedly not at all current).
Heh, we were having that discussion about oauth2 last night
FORWARD SLASH ESS
KAKSOISPISTE DEE DEE
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.
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)
Synology published an update addressing this issue today. So the waiting was not really long…
Yep, Synology wrote in to share a link to their fix with us:
https://www.synology.com/en-global/support/security/Important_Information_Regarding_Samba_Vulnerability_CVE_2017_7494
In what sense is this a great news?
First class, second class, and steerage all go down with the ship.
I would like to introduce you to a concept that many of the visitors here are already familiar with: https://en.wikipedia.org/wiki/Sarcasm
It was a Futurama running (with scissors?) gag.
Holy fuck. You missed the Futurama reference AND the sarcasm tag.
/woosh
And he’s called Edward, you would think he would have heard all the ‘scissor’ gags……….. LoL