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
What exactly is NT Pipe Support supposed to even do? Why would you need it on a file server?
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.
That's the biggest and possibly stupidest straw man on the internet. Read the syntax before after to have a clue about context, or even look up the difference between deep and shallow problems. He didn't say "given enough eyeballs, there are no bugs". In fact, he said there ARE bugs, and he talked about methods of fixing the bugs that are found. Again, he didn't say "given enough eyeballs, there are no bugs". He said the bug would be shallow to someone.
Traditionally the proprietary model is that one programmer owns a module. The same same programmer who wrote the module (and the bug) is supposed to find and fix his own mistake. That model assumes that the person who misunderstood the effects of the ode when he wrote it will magically understand it correctly later. The person who didn't get it right the first time is expected to find their own mistake and magically know the best thing to do instead, the best way to fix it.
Which *is* kinda stupid.
The difference with Linux development model was, Linus said "Somebody finds the problem, and somebody else understands it". Nobody needs to bang their head against the wall for two days trying to figure out a deep bug, to understand why it's wrong, then how it should be rewritten to make it right.
Instead, when shellshock was discovered hundreds of developers looked at the code. Some saw part of the problem, and suggested partial solutions. Florian Mueller's eyes were also on it and he immediately saw what needed to be done. Within 24 hours the community had discussed it and agreed on Florian's solution. Compare Microsoft IE bugs like the vary header bug which was known for 10 years before it was fixed properly; a half-ass bandaid came out seven years after Microsoft publicly ackowledged the bug, but the programmer it was assigned to didn't see a good way to fix it.
Here's the full quote from ESR in context:
--
[Linux avoided] f any serious bug proved intractable. Linus was behaving as though he believed something like this:
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, "Given enough eyeballs, all bugs are shallow.'' I dub this: "Linus's Law''.
My original formulation was that every problem "will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. "Somebody finds the problem,'' he says, "and somebody else understands it."
----
Wrong. Apple switched because Samba changed its license to GPLv3.
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!
Submitter here.
I've been following this with a lot of attention. (here is The Register's take on the matter, by the way: https://www.theregister.co.uk/... )
And I, as many other commenters, think that the real problem is not on linux servers or Workstations with supporrted distros, for which patches already exist, but rather, on many Abandoned Distros, many cheapo NAS boxes, home Routers, IoT stuff and other dohickeys that use Linux on their firmware behind the scenes. I've a synology DS1515+ in my lab at home, and the bug was squashed on may 25, but the fix has not yet propagated to my NAS via automatic updates, but at least there is a fix (and no, SMB is not open to the Internet).
Now, think of those cheapo NAS boxes that do not see a firmware update in years, or those routers with a USB port in the back to slap a USB HDD and "share files effortlessly", or Distros like one of my old time favourites Damn Small Linux. Those are likely So Out of Luck...
No, I do not think this will be a SaMBaPOCALIPE, but I will be bad for some people.
*** Suerte a todos y Feliz dia!
Before you go any further with your criticism of SMB, you might want to disable NFSv4 functionality in any Linux kernels that you are running, as this version was heavily influenced by developments in SMB. Theo de Raadt has particularly harsh things to say about the v4 protocol, but it is in wide use and it solves a number of problems. https://en.m.wikipedia.org/wik...
The advantages play out in statistical trends
Unfortunately the statistics do not help much. Many bugs that lurk for years are incredibly subtle. Many eyes gloss over the same bug over and over again. Short of a security audit by professionals who specialise in the stuff ensuring perfect security and no bad actors is incredibly difficult. How difficult? Well how many open source programs have been properly audited? I can name one: Truecrypt. It had a much smaller code base and still took nearly 2 years to audit. Reading other people's code is hard.
Obvious bugs and stupid bugs typically don't last long in open source software. But really those types of bugs are often caught on code reviews in closed source software as well.
What OSS does do well is provide timely fixes for serious vulnerabilities.
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'." How many years would the bug persist if only a few eyes were looking at the code?
No, to sum it up, you are a moron.
The "many eyes" meme never was about that there would never be any bugs. it's only people like you, who suck on the corporate dick, who ever believed that - because that's what you wanted it to mean, because its obviously not true.
The "many eyes" was about that the more people a bug get exposed to, the greater the probability that someone will come up with a fix. A statement that usually is proved every time a bad bug is found in OSS, because they tend to get fixed in a real hurry. Which is far more than can be said about catastrophic bugs in proprietary software.
And remember, for each bad bugs found in OSS software, how many exists in proprietary software, perhaps not widely known but maybe already exploited?
I'm afraid the the only one who's "disingenuous" here is you, wanker.
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.
Hmm, well if unix premisions are not enugh, giva ACLs a try, if that is not enugh there is alwaysSElinux (but that might be overkill). As for the kernel, procfs and the network stack, I'll take your word for it as I'm not a programmer. I don't think anyone clamis Linux, ot any other os for that matter, is perfect, there are all areas where things can be done betterin any project.