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

Comments

NT Pipe Support?

[Dwedit]

What exactly is NT Pipe Support supposed to even do? Why would you need it on a file server?

Until you have any idea what he's talking about

[raymorris]

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