This article is more than 1 year old
Samba 4.16 release strips away more SMB 1
No one should be using long-dead protocol so it's gotta go
The Samba project just released version 4.16, and with it parts of the veteran SMB 1 file-sharing protocol are being permanently removed.
Among other changes, Samba 4.16 removes the SMB 1 commands that allow a client to request the server copy a file without sending it over the network, and server-side wildcard expansion. Both are rarely used, and this is the beginning of the end for accessing Samba shares from any 20th-century version of Windows. What's interesting is the complex story of why.
SMB 1 was already deprecated and off by default since Samba 4.11. Although SMB over NetBEUI first appeared in LAN Manager in 1987, SMB over TCP/IP is about 30 years old. Microsoft has wanted to banish it for some time. It's been deprecated since 2015, but as late as XP and Windows Server 2003, it was the only version the OS understood.
SMB 2 first appeared in 2007 in Vista and was updated in Windows Server 2008; since Windows Server 2012 R2 and Windows 8.1, SMB 1 has been optional – but it's still there even now. In Windows 11, you can find "SMB 1.0/CIFS File Sharing Support" in the "Turn Windows features on or off" dialog box. We do not recommend ticking it.
Years late to the SMB1-killing party, Samba finally dumps the unsafe file-sharing protocol version by defaultREAD MORE
SMB 2 is a lot simpler, with 19 commands instead of over 100.
Though SMB 1 is disabled by default in today's Samba, there's an ongoing effort to allow the project to be built without it entirely.
If you have some elderly NAS box or something that can't be updated and still needs SMB 1 support, it's time to replace it. Retro computing fans still gaming on Windows 98 or something might want to burn stuff onto CD, or go back to using floppies. As Windows Server 2003's end-of-life was in 2015, a year after XP extended support ended, nobody should be using them any more – but if you still are, you're probably already painfully aware of that. We look forward to your future On Call and Who, Me? submissions. ®
This type of race condition can be exploited by a hostile program to change something in the time window between a program checking it and using it.
In this instance, the trick was to ask the Samba server make a new directory – for example, a new folder called
\\share\docs\letters\. First the server checks that the path exists and that it's entirely within the share, that it doesn't point to elsewhere in the computer's filesystem. So long as the path is valid, Samba creates the folder.
If, in the tiny interval between checking the path and creating the folder in it, the attacker was able to change, say,
letters to a symlink pointing elsewhere in the server computer's directory tree – for example, to link
/usr – the Samba server would happily create the new folder wherever the path now pointed to, letting the client computer access parts of the directory tree that it would not normally be allowed to see. This, for the avoidance of doubt, is bad.
The development team had to come up new virtual file system code to provide a proper fix for the issue. A presentation [PDF] at last year's Samba XP conference explained what they were doing, but not why they were doing it. That story only became public knowledge after the issue was fixed.