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.
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.