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...
does it allow ROOT?
The difference between spam and poop is that you don't have to dig through septic tanks looking for real food. -- Me
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.
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.
well ... windows file sharing is just that ... a security flaw
Makes me glad that I have an SMB block enforced on my rou32der324f[NO CARRIER]
Azh nazg durbataluk, azh nazg gimbatul, Azh nazg thrakataluk agh burzum ishi krimpatul! This sig blocked by Slashdot.
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.
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.
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..
Based on the info http://www.securityfocus.com/archive/1/381420here, it took 53 days from initial contact to public release of the patch (and public notice of the vulnerability). How does this stack up against other OSes?
We apologize for the preceding message. All those responsible have been sacked.
Microsoft did NOT in fact invent/originate SMB. IBM did.
Comment removed based on user account deletion
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.
Your drivers I mean.
Normally, I wouldn't bother to mention about this. But slashdot somehow thought someone mentioning that SP2 was worthless because it had compatibility problems was worth a major mod-up.
So I figure pointing out how Linux also bundles incompatibilities with security fixes should be very well received, right?
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.
ERROR DETECTED
REASON - NFS used with in 10 words of the word secure.
RESULT - AHHHH!!!!
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.
- Never trust your input data - always check it!
- Always check for array-bounds and function return codes.
- Document everything with comments and design documents.
- If you forget a semicolon or close-parentheses, the compiler will try to fix it, but it'll probably do it wrong.
- Always number your punch-cards so that you can resort them if you drop them.
One and a half of those things are no longer true, and most of the security holes seem to come from people ignoring the first two of these principles. I really really like the C Language, but people shouldn't use it for anything sensitive unless they're willing to be really careful, but there's too much badly written code out there.Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Most modern systems can mount webdav to share just fine, you can server it from all kinds of systems and can work with it from just about any kind of system. With ssl you can make it secure enough. So you end up with something nice and fast and where you are free to change implementations at any time on client or server without breaking stuff.
Another option is sftp. I am not sure how easy that is to do under windows and osx but I expect someone has a vfs layer for it under those. Under kde and gnome sftp is transparent to work with and it should be very secure, that is the way I usually share files is with sftp.
The advantage of both of these is that they are entirely user space. Worrying about speed with these file sharing seems seems pretty silly in most cases. You have such vastly more cpu power available then the system needs for file sharing that trading security for speed which is what many of these systems is doing is ridiculous. We should be designing stuff for security first and speed second since who cares how fast a machine can be compromised is. As long as it is fast enough that is fine.
Another thing really needed is more use of safer libraries. Code is not an asset it is a LIABILITY the more of it you have the worse off you are. You need to offload as much stuff to common libraries, using higher level languages which have more safety features built in etc. In the end you will end up with safer and more reliable programs and strangely enough most of them will tend to be faster for many reasons.
Computer modeling for biotech drug manufacturing is HARD!
I have no SMB shares -- I even compiled my kernel without SMBFS support. Honestly, I really don't see the point with SMBFS. All the machines on my LAN have NFS support compiled in, and the ones with printers attached are running CUPS. That seems to work fine.
If I actually wanted to run a Windows box for some reason, I'd probably just run open-source NFS and CUPS clients on that. A non-secret, non-proprietary protocol is always going to be inherently more secure than a secret, proprietary one; because there is a proper distinction between what really needs to be kept secret for security reasons, and what can't be kept secret because the source code is available to all.
Je fume. Tu fumes. Nous fûmes!
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