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'."
I thought that all the people supposedly reviewing the code of open source software would ensure that bugs get fixed quickly. This is frequently used as an argument for using Linux. Please reconcile this argument with the reality that a serious bug lurked for seven years.
Go ahead. Dig into OpenSSL code and tell us if there are any more bugs lurking in there.
Let's put it this way: Somewhere in OpenSSL code, there has to be a pony.
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.
WRONG!
This is a classic slashdot dupe.
https://it.slashdot.org/story/...
Several years ago, Apple stopped including SAMBA in OS X, and instead developed their own SMB protocol stack from scratch.
At the time, it seemed like an odd move for an OS that already contained many F/OSS Projects.
But maybe they knew something that made them feel like it wasn't a salvageable Project...
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."
----
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!
Back when I did use FOSS, I didn't have the inclination, the time nor the skills to examine the hundreds of thousands (millions?) of lines of code written in a myriad of languages.
It's just not possible for an individual who also needs to get things done.
Note that SELinux stops this vulnerability in default configuration.
That's not what the quote about many eyes means!
It doesn't mean that bugs are magically found in open source software. It means that when bugs are found, the cause is generally located quickly because it makes the bugs appear shallow (easy to fix) not deep.
SJW n. One who posts facts.
I have an Archer router which mounts a USB disk and servers it by SMB connection. I'm not skillful enough to know how to look at the router's intimate details. But I would like to know if it's suceptible to this bug. Is there a way one can test this from outside the device?
Some drink at the fountain of knowledge. Others just gargle.
Check this link for a description of SambaCry
https://unix.stackexchange.com/questions/367138/wannacry-on-linux-systems-how-do-you-protect-yourself/367148
Why the heck is this not integrated into the main part of the OS yet? As long as these neck beards keep writing stupid old-school code we will have these problems!
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?
Why would anybody expose a Samba server to the internet?
It can let an attacker move laterally in your network. The "But it is behind a firewall I don't have to worry," is not good security. Someone gets in to your network they are behind the firewall and can make use of it. So they do something like get on to a user's workstation because said user is a dope who will click anything. Ahh but you aren't worried, after all said user doesn't have access to any important data, isn't a local admin and is running Windows. All the important Linux stuff is safe. ...however this vulnerability is still live. So they use that system they are on to scan your Linux shit, find this, and exploit it to move in to those systems. Now suddenly they've infected a bunch of your systems, more important ones, and at a higher privilege. From there they can hop around further. For example maybe you or one of your other admins is lazy and uses SSH keys to auth, and just stores the private key in your home directory for convenience. They get root on a system, find this key, and now can SSH to any Linux system on your network.
Pretty quick everything is owned thoroughly. The fact that vulnerable stuff was behind your firewall meant little, because they found another way in.
The original had it as one sentence with a semicolon or comma as I recall. So you just had to read the entire syntax to understand he was talking about the process after a bug is discovered. The current version has a period, dividing it into two sentences.
My phone wants to say "syntax" everywhere. That should be "sentence". As I recall, in the original text one had to quote just the first four words of the sentence in order to pretend it's not about what happens after a bug is discovered. And ignore the first two words "all bugs" (clearly saying there ARE bugs), plus ignore "are shallow" (the bugs are shallow to fix, not non-existent). So you'd have to a) pull four words out of context and b) ignore the plain meaning of those four words.
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.
Two things here:
1. It's more applicable to once a bug is known than to finding new bugs.
2. Even then it still fails though, as there was a bug in BSD readdir for nearly 25 years. Samba developers had coded around the bug rather than try to fix it. See http://www.osnews.com/story/19...
because Samba is just "not as common as Windows architectures.
There are a *lot* of NAS devices out there running linux with default SMB shares. Updates take some time for them to be prepared - if they are at all. Even longer for them to be installed by users - if they are at all.
Worse, there are probably even more MFD's (Copy/Scan/Print/Fax) devices in every business, corporate, enterprise etc. And they almost all run embedded linux with Samba and default shares, for document storage, scans, secure print etc. And they will almost never be updated - Canon, Ricoh, Xerox, Sharp, Toshiba etc.