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."
It should be clarified, that this is NOT to do with the smbd process aka Samba Project - but the kernel module smbfs.o
Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
I'd like to point out that is a MS originated technology that only got put in Linux for compatibility with MS systems. Most Linux-only users use NFS, which does not have these security holes. Most 'secure' network environments don't even use SMB on windows machines due to security holes in the Windows implementation. My 2 cents, don't use it, its buggy and slow and suchs. On the other hand, many people need to use it in their home networks to share files between windows machines and Linux machines. My suggestion for those users is to set up a firewall which blocks SMB from the outside. And don't make samba shares on your firewall box.
If you like what I've said here, and want to read more, go to http://www.krillrblog.com
Secunia...they also have a free service where they'll email you about vulnerabilities and fixes. And I've never received spam from them. (But that may be due to my GMail account.)
tasks(723) drafts(105) languages(484) examples(29106)
I'll say this once, this is absolutely correct. We've known about this for a long time. SMBFS is deprecated. This is why CifsFS was written. CifsFS is a standard part of 2.6 and is available as patches for 2.4 from samba.org. CifsFS is faster, works with newer versions of Windows better, and is much more secure. More importantly, SMBFS is not being maintained. Critical bug fixes get made but that's only because it's in the kernel. Please don't use it unless you have to. Steve French is the author of CifsFS and has done a fantastic job with it.
This page gives a much better overview of what it is.
More information also here
Probably not. Quote:
SecurityFocus have this down as a "Design Error". Is that in the design of the implementation, or the design of the protocol? Can we start blaming Microsoft for bugs in Linux now?
flossie
Write now. Defend liberty
Slackware, what else when it must be secure, stable, and easy?
The Linux Weekly News security page would be a good place to start. If you then went back and looked through the security pages of the weekly editions, you'd probably have a pretty complete database.
http://lwn.net/security
Linux advisoriese s/index.html
http://www.linuxsecurity.com/advisori
Open Source Vunerability Database (not just for Open source software, but the database itself is open source)
http://www.osvdb.org/
That is probably the best and it offers vendor contact information, detailed analysis and RSS plugins.
Secunia Security and Virus information
http://secunia.com/
Security Focus:
http://www.securityfocus.com/
So on and so forth.
Microsoft did NOT in fact invent/originate SMB. IBM did.
It wasn't developed by Microsoft. It was originally an IBM protocol, which was....are you ready?....extended by Microsoft to get what we know today as SMB.
"City hall" in German is "Rathaus" Kinda explains a few things......
Looking at their schedule, it is unclear what actually happened. Note that on 25 September 2004 they made their initial contact, but on 22 October 2004 they say they sent a second round of vulnerabilities in, followed by a set of patches on 27 October. The developers would then have to take all these patches, compare it to anything they may have come up with in the meantime, and make sure they didn't break anything else.
The public disclosure occured 17 November 2004, about 20 days later, after about a week's worth of testing time as 2.4.28-rc3. Personally, I would not have liked them to have announced on the first set of vulnerabilities if there was some knowledge between October and November that more issues were being found. Otherwise everyone and their kin would be combing the code looking for any issues missed in smbfs.
After these minor changes that took me all of 3 minutes to make, I no longer have smbfs anywhere on this network.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
it's the only place that has millions of dollars at it's disposal and highly paid programmers.
But Linux is supposed to better because it has armies and armies of passionate volunteers.
I don't respond to AC's.
Filesystems by necessity have to be implemented to some extent in the kernel because they have to hook the VFS layer. However, you make a very good point that it does seem to be a big risk to implement the entirety of smbfs in kernel space.
Recent Linux kernels (I think 2.4 onward) have a mechanism for doing what are called user space filesystems. Basically, the kernel only knows enough to talk to a daemon which implements the filesystem and exposes it to the kernel. In this manner there is a very well defined interface between the kernel and user code which hopefully is bug free.
In some ways this is sort of a partial microkernel design. With that comes the inherent loss of speed having to do the context switches between kernel and user mode. In the normal filesystem case you have a context switch from user to kernel mode, the file is accessed, and then back to user mode. In the case of a filesystem implemented in user mode you have to switch from user mode to kernel mode, then to user mode in the FS daemon then back to kernel mode then back to user mode in the process trying to access the file. And that is the best case. Throw in a scheduler without the knowledge of which process is waiting for what and messaging between two user space processes through the kernel can be extremely costly!
In this case, yes, I think I probably would have recoded smbfs to use the user mode filesystem handler. But the code was already written years ago to live entirely in kernel space before there was really any sort of well defined standard for a user space file system. Given that this is as far as I can remember the only major bug in it one might say that it hasn't really been that bad having it in kernel space.
So the tradeoff becomes do you want to have it in user space (where it would still vulnerable to DoS in this case) and sacrifice some speed or do you want it to run in the kernel at full speed?
Jeeze, if you're going to the trouble of posting a link to xscreensaver, you might want to use the right one so you get an up-to-date version (4.18 is current).
- chrish