Slashdot Mirror
Security Flaws In Linux SMBFS
An anonymous reader points out this SecurityFocus alert, which starts "The Linux kernel is reported susceptible to multiple remote vulnerabilities in the SMBFS network file system. These vulnerabilities may lead to the execution of attacker-supplied machine code, information disclosure of kernel memory, or kernel crashes, denying service to legitimate users. Versions of the kernel in both the 2.4, and the 2.6 series are reported susceptible to various issues."
Not to sound like a flaimbait, and yes, I use and love linux, but this is some proof that micro$oft isn't the only place in the world that puts out code with security holes in it.
Not all of us here point and laugh every time Microsoft has an exploit.
I think that one of the major misunderstandings that many people have is that software will be absolutely perfect. It won't be. We deal with systems with many layers of complexity, and sometimes these things fall through the cracks.
If you want a perfectly secure system, you'll have to audit the code personally.
Cb..
This (parent)notice should be added to the headline as a public service.
Most Linux-only users use NFS, which does not have these security holes.
But does have a bunch of its own, some of them uncorrectable as they are design issues. Sigh.
I can hardly believe any "secure" network would allow NFS. That shite doesn't even have any authentication and has numerous means of DoSing the server.
*(Unless you are running v4 which only became available recently.)
So which is worse: implementing a technology that turns out to have security holes or adding a technology you already know has security holes to your system in order to be compatible with a system you claim is inferior?
"Most Linux-only users use NFS, which does not have these security holes."
Yeah... it NFS just has plenty of holes of its own. I would be the first to say that I think that SMBFS is crap, but NFS isn't the network filesystem that we should be holding up as a good system to emulate.
a compromised machine is:
a compromised machine.
remomove from the LAN/WAN, disect then reinstall. Its the only safe way.
Fry: heh, Yakov Smirnoff said it
Leela: No he didn't.
If it involves a buffer overflow then it's a 100% Pure Linux Fuckup.
I don't know how many times I've heard clueless admins tell me that they aren't patching for something because its only exploitable locally...
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
You seem to be reaching here. If implementing the protocol safely is beyond the ability of Linux developers, then they shouldn't do it.
More likely the truth is that smart developers for Linux and smart developers for MS make mistakes and will continue to do so. My only complaint is that there shouldn't be a double-standard.
Because linux does not fully support an implimentation any longer - an implimentation spec that was long ago abandoned by the people that made it, No, the Samba community provided smbfs to solve a problem and now, we've done a rewrite and we have cifsfs. It's still a product of the Samba community. The argument is more analogous to someone saying that FireFox 0.1 has does not support SSL and therefore is insecure. Well, hell, that's why there's FireFox 1.0. Upgrade and get over it.
No particular beef with your post - as you mention, NFS security isn't good. Put another way, it's as good as your network and host security, but relies on proper configuration of server and client. That said, NFS for being the pile of shit it is has survived through virtue of being widely supported and mostly compatible, robust in the face of server outages (as opposed to SMB's "oh, I guess you'll be losing the latest copy of your work now"), easily clusterable, scalable to several dozen busy clients, easy to manage, very well understood, and free.
No one in the know would hold the NFS security model up as one to emulate (you're of course absolutely correct about its security only being up to physical control of every machine on your network), but facts are, NFS continues to help people get the work they care about done. One can only hope that better solutions might finally be implemented to drive a worn-out protocol out of business, but it isn't there yet (I'd like it to be AFS, but on Linux, scalability doesn't seem to be on par with NFS).
NFS was a pragmatic solution designed by smart people in a time where talk, finger, telnet, RIP and rsh were all used freely. Now that networks are chock-a-block with assholes, NFS looks about as good as those other protocols - but people look a lot worse.
sloth jr
Ok, but who cares if the kernel is secure when all of your critical userspace utilities are fried anyway?
it has to be said CIFS is not mature yet (that's great seeing active developement there though)
Yes, CIFS has some bugs in it. However, so does SMBFS. In a lot of ways, SMBFS was never mature to begin with.
<i>how to you connect to legacy SMBFS servers which do not support CIFS</i>
The story basically is, SMBFS is there for that, however, if there is sufficient demand for legacy compatibility, I'm sure cifsfs will try to support it. It's not that difficult to do, just a matter of prioritization.
Open Source software only gets mature if people use it and submit bug reports when they encounter problems. If you want something to work better than smbfs and to not have gaping security holes the answer is to use cifsfs and file bug reports at https://bugzilla.samba.org.
Kind of. This is Microsoft marketing at it's finest. SMB is a protocol for sharing files. When the internet took off, Microsoft rebranded SMB as CIFS (or Common Internet File System). It's totally a marketing different. Both smbfs and cifsfs use SMB for file sharing (it's the only way to do file sharing). The main differences in smbfs and cifsfs are 1) performance 2) unicode support 3) authentication. cifsfs has much better performanced, negotiates unicode over the wire, and more important, uses a much stronger form of authentication (ntlmv2) than smbfs (lanman+ntlmv1). In fact, the authentication that smbfs is pretty much plain-text equivalent. Not to mention that smbfs does not support any sort of signing/sealing mechanism leaving your sessions wide open for hijacking. At the end of the day, keep in mind though, that NFSv3 and below have an even worse design in terms of security. This is why you don't expose things like NFS and Windows file sharing over the internet. They just aren't normally very secure.