Years late to the SMB1-killing party, Samba finally dumps the unsafe file-sharing protocol version by default Samba says its next release will switch off previously on-by-default support for the aging and easily subverted SMB1 protocol. It can be reenabled for those truly desperate to use the godforsaken deprecated protocol version. The open-source SMB toolkit's developers say the Samba 4.11 build, currently in preview, will by …
Agreed. Computers were new and very intimidating to the average Joe who found them complicated enough. Adding a modem and dialing to some number was almost akin to witchcraft. Very few people needed to do that, but those who did had to learn everything themselves, because there was no Internet or Google to help them find the way.
So not only did most users work unconnected, I'd wager that most of them didn't even know you could add a modem for quite a long time.
"you'd sit there for hours typing in to get some really quite crappy games."
You got games? In my day, all we got were primitives after bashing t'keyboard (or something). In an ideal world I would now reveal that I'm a games developer that would make Jeff Minter look square thanks to bashing in shit loads of very short int (0-255) laden data statements on my trusty C64.
I still have my C64, an IT company and consider myself a reasonable sysadmin. I have zero imagination (for games) and near zero ability in anything more complicated than English as a language. I can mumble perl and python and sound ridiculous in French and comical in German.
This post has been deleted by its author
Schwarzenegger Van Damme, Lungren ?
I hear the young praising Cleese, Moore, Connery, Redford and other actors active in the 70's and 80's, surpassing anything on the silver screen these days, forgetting oh so conveniently that we had our share of rubbish acting amateurs as well ...
Icon ? Pint o'clock where I am now ;-)
SMB -- Server Message Block -- protocol predates the 80s., its an old Xerox protocol that ran directly on 802.3 packets (802.3 is "Ethernet like" it uses what we know as the message type field as the packet length). Its actually really secure because it can't route so people eventually encapsulated the packets as UDP traffic. That would have increased the range of possibilities to exploit/abuse it.
You'd have come across SMB traffic with by PC-NET (IBM) and MS-NET (Microsoft). It handily predates Windows by many years (assuming you ignore Windows 1.0 -- I know its trendy to try to 'run' it but it was pretty naff in the 1980s -- "totally unusable" -- so its probably not improved with age).
(I don't think you'd have a problem with malware being shared using BBS because back then it would never have occurred to anyone back then that pushing executable onto a remote machine was a smart thing to do.)
.... now, if the *nix desktop admins at my former workplace had forced the clients to use > version 2. The printserver was changed at one point to no longer acccept v.1, and that is of course a good thing. However, the client software (like... user authentification to print on "special" printers) did not like that. Let's hope that the Linux distributions follow suite and disabel the f'ing mess that SMB v.1 is by default, as they should have done a decade or so ago.
"As Microsoft doesn't support anythiny but their most recent products, it is important to be able to still use SMB1 as that's what a _lot_ of Windows machines only support.The SMBv2 protocol was introduced in Windows Vista and Windows Server 2008."
The SMBv2 protocol was introduced in Windows Vista and Windows Server 2008.
The SMBv3 protocol was introduced in Windows 8 and Windows Server 2012.
In fact MS recommended NOT disabling 2&3 as it would break many services.
As some embedded systems use SMB1 it is reasonable for Samba to still have it available for those cases. Having it off by default makes good sense.
(Some embedded systems still use W95 or W98 - often with long lost source code so updating them to newer more secure protocols is not practical.)
A few years ago I was doing support for an industrial company making plastic wrapping. As usual, I was working in the IT Admin's bureau because that's where the development PC was, so I was privy to all their conversations, and one conversation was about updating to Windows 7 (at the time).
Their situation is as follows : their production floor is based on machines that are piloted by WinXP PCs who use drivers that are undocumented, talking to the machines using a protocol nobody knows. The pilot app was coded about twenty years ago and has survived upgrades from Win 3.11 to Win XP, because the guy who coded it all was still around to help. That is no longer the case (and that there is your long lost source code).
So, in order to upgrade the PCs, either they have to commission the complete rewrite of the drivers and the apps based on unknown rules, which will take vast amounts of time and an ungodly amount of money, or they can replace the production machines, which will cost upwards of a quarter million per unit, which them has to be configured with a new PC and a new app, and that throws their entire production line under the bus for weeks at a time.
So yeah, upgrading Windows has kinda hit a brick wall there. Thankfully, the admin is not stupid enough to have the XP systems connected to the Internet, but they are on the network, so there is a risk despite the firewall cutting them off from all but the admin PC that is overseeing them (not the admin's PC, that's a different one).
Until recently I had PCs driving Inkjet printers on the production line. They were running DOS6 and a custom application that talked to an Oracle database, and had PS2 keyboards with inline barcode scanners. We never saw a need to upgrade to Windows in the early 90's, if it isn't broken, don't fix it (although we were beginning to run out of spares).
We only replaced them as the inkjet printers were replaced.
Automation for industrial production requires a different mind-set from office applications. People in the early days of the personal computer had that mind-set because they were the sort of people who tinkered with stuff and a soldering iron was as much part of their lives as a keyboard.
Then the personal computer became the PC that approach became a minority interest and as MicroSoft became Microsoft they had no time for those who were their customers in the early days - the new market was much bigger. That mind-set has been lost.
"I think what he means is that it's another security exploit vector. Find ANY exploit that silently switches smb1 back on and then use the copious amounts of ready made exploit code for smb1."
Don't think that's a problem -- the samba code is fairly clean in terms of turning things on or off via a config file (which, as usual in UNIX, is not writeable by regular users.) I'm quite confident you would not be able to just turn smb1 back via samba itself.
Why, that already happened, when it got turned off-by-default in Windows long ago.
FWIW, I'm surprised that "we'll ship a different default config" warrants an article. Reading the leader, I expected it to be "this is now a compile-time switch that defaults to off", and frankly, I'd be not surprised at all if all major distros already ship a stronger default config.
I got quite a lot of calls from folks who couldn't hook up to their NAS after an update, about 2 years ago.
I looked up what the issue was and just switched SMB1 back on. However, as I mentioned earlier it was the wake up call that those devices were on death row from that point.
It was quite handy as I hated them. They only managed around 10MBps with the encryption enabled on a gigabit connection.
No. We've already had that.
If you are imagining loads of non-technical end-users losing contact with the NAS boxes, then you are probably imagining Windows users, who lost SMB1 support (by default) a little while back. Any users disappointed by this announcement are Linux-heads and presumably know how to modify /etc/samba/smb.conf.
We've also already had the complaints when Microsoft stopped tolerating LAN manager passwords and people discovered that their NAS had been configured to use those and the NAS box's smb.conf was not accessible because the vendor had locked the device down.
Your data isn't secure if you're using an entirely-broken protocol to store it.
It's not like you *can't* get your data back out, it just won't be automatic.
Anyone with a NAS that doesn't allow web-access, SMBv2+, etc. anyway is throwing their money away on useless junk and probably needs to update quite substantially anyway, before that thing dies.
You can't keep everything around for the sake of convenience "just because it used to work".
SMBv1 has been known insecure since the days of Server 2003. You need to upgrade once every 15 years or so. Or implement the well-documented "this is insecure" workarounds that are all over the internet.
Seriously, it's like whining that you can't do NetBIOS over IPX any more... get with the program if that data is of any import, and upgrade/reconfigure/replace. If it's not, then you'll tolerate loss of immediate access to that data anyway.
You wouldn't expect a car to last 15 years without maintenance, let alone some crappy Chinese cheap NAS box that doesn't support anything other than SMBv1.
I've been told that yes, they're aware they're still running smbv1, but they can't update it because the branch of Samba with >SMBv1 support is *massive* and simply won't fit in the available flash memory.
The mythical unattributed source also claimed there have been backporting efforts to get >SMBv1 support in the lean and "unbloated" branch of Samba, but it's too unstable to be deployable.
So yeah, this is my usecase for SMBv1 too, harddrive hooked up to WiFi router, and PCs backup to that network drive. And I'm too cheap to pay for a router with enough flash to fit recent samba. :-)
Back when Andrew Tridgell was building the first version of Samba, he didn't even know that there was such a protocol. He had a copy of DEC Pathworks running, which was a product that allowed DEC machines to act as file servers to DOS and Windows clients. And he basically reverse engineered it, byte by byte, until he had an equivalent server running. There were opaque blobs of bytes that he just reproduced without knowing what they did.
So ... hats off to an excellent hacker who produced something very useful, even before he understood the protocol he was implementing.
Since then the SAMBA project has turned into a complete monster, with horrible/buggy code (regular CVEs - it's a genuine surprise when a new minor release doesn't include a fix for one or more security vulnerabilities), and the WAF build system is a nightmare of epic proportions.
Samba developer here, responsible for some of the CVE's you're laughing at :-).
Yes, complex software has security bugs, especially if it's written in C. The measure of a project is how it handles them though. I'd argue the fact we report and fix our CVE's makes us *more*, not less trustworthy.
There's no hiding your bugs in FLOSS code.
I agree with you on waf though, but most of the Team members just love python code, so what can you do :-). If I'd had my way it'd probably have been cmake instead, but you have to compromise with your colleagues to get anything done at all.
If you contribute to FLOSS code you'll know what I mean :-).
It's clunky, but a lot of that is that the protocols they support are clunky things designed incrementally, with obscure and bloated specs.
Mind you, starting from a clean sheet doesn't always help -- I was trying to run NFSv4 for a while and the number of bugs in the Linux kernel implementation of that were just amazing. Eventually I switched to NFSv3 because it performed better and was less buggy.
Some of the large printers/copiers/scanners used by small offices (and commonly leased from 3rd parties with little or no config support) have SMB1 as a default scan to pc method. There are workarounds such as usb stick or email or ftp of course, but it takes a while to figure out why something that worked for 5 years suddenly doesnt. Users and techs like to blame it on Windows 10 updates, and they would be correct in this case.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
