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.
This is a classic slashdot dupe.
https://it.slashdot.org/story/...
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.
Strawman argument. Open source allows the possibility. It does not guarantee it.
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...
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.
No, no, and no. Nobody ever said, "With enough code in the world, eyeballs will look at it." Nope. That wasn't it.
"With enough eyeballs, all bugs are shallow." OK, that one I've heard. Nothing there about, "If you write it, they will read it" or anything like that.
If nobody is looking, there are no eyeballs, so no affect would be expected.
But once the bug is discovered, now there are lots of eyeballs! And it gets fixed fast, nearly instantly. That's what happened here. It is true that DoD clown made a political anti-FLOSS statement that contains the same mistake as yours. But he was at work, for the government, he's supposed to do a mediocre job. You're posting on slashdot. You're supposed to be slightly less stupid.
For the bugs to be fixed before being found, you don't want linux; in linux the eyeballs are mostly focused on writing new stuff, supporting new hardware, etc. If you want boring old code to get the eyeballs, you run *BSD where new stuff arrives in 10 years after 37 audits, and there might only be 9 eyeballs working on the whole thing, but they re-read old code as their sole hobby, and fix sloppy code even where they don't know of bugs.
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.
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.
Samba existed before Microsoft implemented SMB.
"First they came for the slanderers and i said nothing."
Check this link for a description of SambaCry
https://unix.stackexchange.com/questions/367138/wannacry-on-linux-systems-how-do-you-protect-yourself/367148
Basically, more bazaar-style, less cathedral. The "short on developers" problem isn't so much a matter of open vs. closed as it it resource allocation. Just about any project is going to have problems if you lack adequate manpower, and while going FOSS might help somewhat, it's nowhere near a complete solution.
This is my signature. There are many like it, but this one is mine.
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?
But he was at work, for the government, he's supposed to do a mediocre job. You're posting on slashdot. You're supposed to be slightly less stupid.
Two statements which suggest your set of beliefs are built on shaky foundations.
"Old man yells at systemd"
His argument was, given enough eyes, all bugs are shallow. If the bug isn't shallow, you don't have enough eyes, and the number of eyes to constitute 'enough' may be incredibly high. The difference between the metaphorical cathedral and the metaphorical bazaar was specifically about how different FOSS projects can have drastically different numbers of eyes looking for bugs.
This is my signature. There are many like it, but this one is mine.
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.
SMB is an IBM protocol. Even if the protocol is bad, there is no excuse for sloppy coding.
Nope, it started as a DEC protocol.
227-3517
statements which suggest your set of beliefs are built on shaky foundations.
Well if I posted them on slashdot, that's guaranteed.
I would not get my physics constants from slashdot comments, either.
I agree with what all the Courts say about Government workers; they're not expected or required to do a great job. "Good enough for government work" is not a high bar. It is a much lower bar than "good enough for an industry professional." But the lack of profit motive is supposed to balance out the quality difference. It often does.
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.
NASA is also government work.
Building dams that could kill you when they collapse is also usually government work.
You guys should get out more.
I'm in private enterprise myself BTW so the usual kneejerk personal attacks to an inconvenient opinion are going to be a little bit trickier aren't they?
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.
And I guarantee you that exploitable bugs remain in Truecrypt. Audits are great, fuzzing is great, good security development practices are great... but secure software is devilishly hard to build. Projects, open or closed, should do all of the above, and they should all encourage researchers to regularly analyze their work, because all of that reduces the number of security vulnerabilities, making the ones that remain ever more subtle and hard to find. But bugs *will* remain.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Do you kiss your..... never mind.
... in a distributed fashion.
I suppose some people might say that the greatest problem with the open source is people like you... I know that I have been involved with multiple open source projects until people like you came around and I decided it's just not worth my effort. The guy above came off as a know-it-all. Fine. But he wasn't rude and he made some valid points. He is attempting to raise awareness as well as advocate merits of open source while suggesting people shouldn't just blindly expect the code to be perfect.
Consider the Linux Kernel for example. The Linux Kernel is one gigantic, glorious and wonderful shit heap of code. It is riddled with security problems. There are probably 2000 functions that do the same thing spread out over the code base. The GPL has been awful for the kernel at times since developers writing drivers... which of course are always monolithic... must either reinvent wheel after wheel after wheel (rbtree.h and rbtree.c for example) since the GPL on that code means that they can't use that code for closed source drivers on other operating systems. The network stack as it stands right now has grown far too complex and can never be rewritten as the project would be too large. There needs to be a revisit to devfs and procfs to make it cleaner and more secure. Oh.... and if someone were to completely drop the unix file permissions model and implement something more intelligent, that would only require rewritting most file systems and probably... you know what... it's not even worth trying to map that scope.
Linux gets fixed quick.
But it has a development team which is paid for
And it has project management.
And it has testers.
And it has extensive quality control.
Which works kinda ok...
As for open vs. closed... I discovered about 50 minor to devastating zero-days in a specific Cisco product which most governments depend on this year. What's worse is, I wasn't looking for them. I stumbled on them while writing some code. I have not released them and I can't seem to figure out who to talk with at Cisco to get them sorted... unless I release them and screw all my customers by doing so. And I have deadlines to meet... and I just don't have the time to deal with it.
Here's the kicker.... 3/4 of the hacks were because Cisco blindly uses open source products (they follow licenses) which if you don't apply patches weekly or more often are security disasters. Then, there's the issue that if they patch those products, then they have to write new code to work with the patches. Which they don't... so they don't patch the open source code. So they don't get the security fixes.
That means, vulnerable versions of JBoss, OpenSSL, Java, MySQL and far more. Even if Cisco's tools were open sourced, it is perfectly clear to me that their QA team doesn't employ unit tests or automated testing. So those vulnerabilities are actually in poorly managed open source code within a commercial product.
So.... thankfully you posted that as AC, you'd only embarrass yourself otherwise.
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.
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.
Given Apples track record with other OSS projects its more likeley Apple just could not interact well with the upstream project. Im thinking in particular of the KHTML/WebKit fiasco
The "fiasco" that resulted in nearly every single browser switching to WebKit? That one, right?
Tells me that the real problem was with the KHTML Projext, not WebKit.
Wrong. Apple switched because Samba changed its license to GPLv3.
So, if that's the real reason, that means that most Slashdotters would agree with Apple's decision to go their own way, right?