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."
you haven't emulated SMB unless you allow remote execution of code ;)
https://www.gnu.org/philosophy/free-sw.html
Does anybody know of some website or source that's been tracking these kinds of linux exploits, including the date and nature of both the exploits and the fixes?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
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.
well ... windows file sharing is just that ... a security flaw
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
Major distributions will have patches available. Possibly even the main kernel tree.
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
SP2 users are unaffected.
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
Now, I'm definitely not a Microsoft fan (see my sig), but does it strike anyone else as a little scary that it took 2 months to get this fixed properly? I mean isn't that one of the main benefits of open source is that it gets fixed faster?
Your Windows PC is my other computer.
Just wondering if the SMBFS kernel option in EreeBSD has the same vulnerability
$FreeBSD: src/sys/fs/smbfs/smbfs.h,v 1.8 2003/02/08 05:48:04 tjr
To blog is sublime
Cb..
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.
The difference is that this is a POTENTIAL exploit. Not something that's been known for a long time but ignored to the point of mass-exploitation.
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.
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)'
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?
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.
more than root
...God?
-- "I can't tell the future, I just work there." -- The Doctor
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