Wormable Code-Execution Bug Lurked In Samba For 7 Years (arstechnica.com) 83
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'."
Re:Wait, what?! (Score:4, Insightful)
Re:Wait, what?! (Score:5, Informative)
Re: (Score:3, Insightful)
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 (window
Re: (Score:2, Informative)
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 rea
Re: (Score:2)
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 th
Re: (Score:2)
Re: (Score:1)
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.
Open as in a good way, or open in a bad way? I can see the whole "develop in secret, dump on community" model can have its faults. So can the "we're so short on developers anyone who takes any real interest will get commit privileges" model. I mean, it's one thing to believe that eventually someone will spot an existing bug, but the vast majority of bugs are caught in development as the code is written and - hopefully - reviewed. Security bugs often come from unclear or sloppy code, standards differ wildly
Re: (Score:2)
Re: (Score:3)
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.
Obv
Re: (Score:2)
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.
Re: (Score:1)
Strawman argument. Open source allows the possibility. It does not guarantee it.
Re: (Score:2)
Re: (Score:2)
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.
Re: Wait, what?! (Score:3)
Re: (Score:2)
Re: (Score:2)
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 polit
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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?
Until you have any idea what he's talking about (Score:3, Interesting)
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 pr
Re: (Score:2)
Is the quote from V1 of TCATB that I read in 1996? or the quote of the current version (3.x I believe)?
Anyhow. "almost every problem will be characterized quickly". Well, this is one of the ones who forces you to use almost instead of always.
Again. FOSS is cool. and many eyes are nice. But many eyes are not a panacea or a silver bullet.
older version it was a semicolon or comma. Debuggi (Score:2)
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.
Autocorrect fail: Sentence, not syntax (Score:2)
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.
My example finding a bug in the kernel (Score:5, Insightful)
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.
NT Pipe Support? (Score:4, Interesting)
What exactly is NT Pipe Support supposed to even do? Why would you need it on a file server?
Re: (Score:2)
Re:NT Pipe Support? (Score:4, Informative)
Submitter here.
From the SUMARY: "The change will prevent clients from fully accessing some network computers and may disable some expected functions for connected Windows machines."
So, it seems that your connected Windows machines use the expected functions that the setting disables.
Go figure.
Good though to know one of the error messages that may arise after turning of the setting.
Re: (Score:3)
Instead of that setting, you can also mount the filesystem for the samba shares using the noexec option. Not sure if that also impacts windows access, though.
Some SELinux configurations, such as on RHEL/Centos will prevent this too. "SELinux is enabled by default and our default policy prevents loading of modules from outside of samba's module directories and therefore blocks the exploit." For people more affected by it, copying the SELinux configuration might be the best short term option, though it is a l
Re:NT Pipe Support? (Score:4, Informative)
Re:NT Pipe Support? (Score:5, Informative)
From the manual:
nt pipe support
This global option is used by developers to allow or disallow Windows NT/2000/XP clients the ability to make connections to NT-specific SMB IPC$ pipes. As a user, you should never need to override the default:
[global]
nt pipe support = yes
How can I test for this on my router? (Score:2)
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?
Samba connected to the Internet? (Score:5, Insightful)
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.
Re:Samba connected to the Internet? (Score:5, Informative)
And worms aside (Score:2)
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. ...howeve
Re: (Score:3)
I can't think of any reason why you'd do that anyway
stupidity?
No he was not the first (Score:1, Informative)
This is a classic slashdot dupe.
https://it.slashdot.org/story/... [slashdot.org]
Re:Maybe Apple was right (Score:4, Informative)
Re: (Score:2)
Wrong. [slashdot.org] 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?
Re: (Score:2)
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.
Linux in firmware for NAS and other Dohickeys (Score:3)
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/... [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.
Re: (Score:2)
How can I test my NAS? I have no way to look at it's internals. But maybe there is an external way to do this (e.g. run the worm?)
Re: (Score:2)
Submiter here:
You can use metasploit, which already has incorporated this bug.
From the article on "El'Reg"
"Re: Samba bug, the metasploit one-liner to trigger is just: simple.create_pipe("/path/to/target.so")"
Re: (Score:2)
I just contacted TP-Link the maker of Archer routers. They claim that they use Linux but they do not use SAMBA. I'm skeptical. Is there something other than SAMBA for doing SMB communications on Linux?
Re: (Score:2)
it's an smb connection for sure. They are claiming they don't use SAMBA for that. I doubt them.
Re: (Score:2)
Re: (Score:2)
Nothing really is out of luck. These machines should not be exposed to the wider internet. People who are stuck in a situation where this affects them should look in general at their network management rather than this specific bug.
NASes and similar should be internal to the network. ... well let me say I'm not concerned about the samba bug but rather the entire device itself. Those "share files effortlessly" on the WAN side should never be doing it via
Routers which are exposing samba to the wider internet
Re: (Score:3)
Submitter here:
Even if machines or NASes are internal to the network, someone may send you a boobytrapped email or webpage, and infect the suceptible machines from INSIDE the network, sort of like one of the modes of contagion from the WCry worm
Re: (Score:2)
If you can write an email to either automatically do or manually convince a user to upload a specially crafted payload to a writable share, no amount of patching it going to render that network safe.
This is orders of magnitude harder to do from outside the network as you require knowledge of the network setup itself. Then you need to craft an attack specific to that network, and then you need to get the user to fall for that attack. Too hard, just get a user to type in his bank details into a phishing site
Re: (Score:2)
Re: (Score:2)
Which brings me back to my original comment: Bug mostly defeated by network design which reduces its severity by orders of magnitude.
SELinux (Score:1)
Note that SELinux stops this vulnerability in default configuration.
Re: (Score:1)
ayy lmao
and introduces how many others?
that's not what it means! (Score:2)
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.
SambaCry (Score:1)
Check this link for a description of SambaCry
https://unix.stackexchange.com/questions/367138/wannacry-on-linux-systems-how-do-you-protect-yourself/367148
How many years would the bug persist if only... (Score:3)
I don't get it. (Score:2)
Re: (Score:2)
you usually don't. But once this thing gets trojaned onto one computer on an intranet, it worms the whole thing.
The "Many Eyes" Thing is BS (Score:1)
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... [osnews.com]
Not as common as Windows Architectures? (Score:2)
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