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.
Submitter here:
I agree with you 100%. The point is that many people in the FOSS community think that the many eyes are indeed a magic bullet, and the only thing needed to weed out bugs, when, as you said, is not.
If you see my post history, you will see that my long standing oppinion is that many eyes are not enough. One needs ENOUGH Qualified AND Motivated eyes, as well as test cases and structured QA.
I came to that realization during the Metafile Fiasco of Dec. 2005.
We had two codebases, one Closed (windows) and One Open (wine). Neither was able to realize the security implications of the code. It took a third party (sysinternals IIRC) to realize the security implications. Even with many eyes, no one in the wine team realized the security implications of the metafile behaviour. At the time some people said "That's because the wine team were copying the behaviour of windows"
That is disingenuous, for if the wine team had realized the security implications, they would had bang on that drum like crazy, and made a config option of the form [metafile bug=0, 1, 2] 0=keep error for compatibility; 1=wineteam fix; 2= microsoftfix if and when released...
So, to sum up. Many eyes are nice to have, but not a panacea. For good code (less bugs, less security issues), one needs not MANY eyes but, ENOUGH QUALIFIED AND MOTIVATED EYES (of course, if you have many eyes, you MAY get ENOUGH of the eyes you need, but it is not guaranteed). Also, for good code one needs good test cases and a good QA process.
*** Suerte a todos y Feliz dia!
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.