Slashdot Mirror
Wormable Code-Execution Bug Lurked In Samba For 7 Years (arstechnica.com)
Long-time Slashdot reader williamyf was the first to share news of "a wormable bug [that] has remained undetected for seven years in Samba verions 3.5.0 onwards." Ars Technica reports:
Researchers with security firm Rapid7...said they detected 110,000 devices exposed on the internet that appeared to run vulnerable versions of Samba. 92,500 of them appeared to run unsupported versions of Samba for which no patch was available... Those who are unable to patch immediately can work around the vulnerability by adding the line nt pipe support = no to their Samba configuration file and restart the network's SMB daemon. The change will prevent clients from fully accessing some network computers and may disable some expected functions for connected Windows machines.
The U.S. Department of Homeland Security's CERT group issued an anouncement urging sys-admins to update their systems, though SC Magazine cites a security researcher arguing this attack surface is much smaller than that of the Wannacry ransomware, partly because Samba is just "not as common as Windows architectures." But the original submission also points out that while the patch came in fast, "the 'Many eyes' took seven years to 'make the bug shallow'."
The U.S. Department of Homeland Security's CERT group issued an anouncement urging sys-admins to update their systems, though SC Magazine cites a security researcher arguing this attack surface is much smaller than that of the Wannacry ransomware, partly because Samba is just "not as common as Windows architectures." But the original submission also points out that while the patch came in fast, "the 'Many eyes' took seven years to 'make the bug shallow'."
No need to reconcile, just imagine how many of those bugs lurk in closed systems like Windows, where no-one can see them.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I think you'd find the risk can be mitigated significantly by simply not allowing Samba to connect to the Internet, I can't think of any reason why you'd do that anyway. It's designed for local resource sharing, not Internet transfers.
FOSS isn't a magic bullet, it's a development model. The advantages play out in statistical trends, and the differences in those trends can depend on many factors, including how 'open' development is. For example, WannaCry is somewhat comparable, and since it affected XP, the issue likely existed for at least 9 years, if not longer.
This is my signature. There are many like it, but this one is mine.
Wrong. Apple switched because Samba changed its license to GPLv3.
From the manual:
nt pipe support
This global option is used by developers to allow or disallow Windows NT/2000/XP clients the ability to make connections to NT-specific SMB IPC$ pipes. As a user, you should never need to override the default:
[global]
nt pipe support = yes
The words Linus used at the time to clarify the debugging process were:
"Somebody finds the problem, and somebody else understands it."
Here's my own personal example. I discovered that there was a bug in the storage stack, which caused writes to eventually fail under certain conditions. I had no idea where in the code the problem might be; didn't know which source file to start looking in. I posted the problem to the appropriate mailing list (LVM-DEVEL). Somebody on that list immediately recognised that a different group, a different mailing list actually owned the problem, md-devel.
I posted the problem on md-devel. Somebody quickly replied that the problem would most likely to be found in a certain source file, and told me how to start debugging it. I did as he suggested and an hour later got to the end of my ability again, so I posted the results. Neil Brown, Linux RAID maintainer, looked at my results and knew exactly what must have caused it. He emailed me a fix for the within a few minutes. After I tested the fix, Neil committed it to the kernel repo.
It would have been impossible for me to fully characterise the problem myself, much less fix it. Neil Brown knew the code inside and out but never saw the bug until I pointed it out. With three or four sets of eyes on it from different perspectives, we found and fixed a tricly bug without any of us spending days trying to figure things out. What I found made the issue transparent to Neil, though it was totally opaque to me.