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?
Very few vulnerabilities in Unix Operating Systems allow a hacker to gain control of the machine provided the machine is being run by a competent person. This is due to the fact that Unix/Linux/BSD/etc tend to be modular whereas every thing in Windows is integrated. To answer your question, the vulnerability discussed here allows someone to crash the system but does not allow them to take over the computer.
BSOD screensaver
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.
Someone tell me there is a better solution. I want a 'pay once but free update for 5 year' solution that other OS vendors offer.
/me ducks
I believe that is how Windows Update works.
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......
Actually, RedHat 9 updates are still available through the Fedora Legacy project (http://www.fedoralegacy.org/). Payment not required (though I'm pretty sure they'd like a donation or two)
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.
It is very wrong to assume some Linux hobbyist will quickly put aside other things in life, to patch a bug like this, which will make companies like Redhat, novell richer.
..except theres no SCO code in there.
Opensource does not guarantee quick fixes of bugs. Case in point.. many ATM cards remain in the experimental stage and crash on atmsigd 6 years on. Similar bugs with the arcnet driver will probably never be fixed.
Opensource software is 'generally' better in quality and security, but there are absolutely no guarantees.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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?
Not a website, no specific tracking but at you can be smarter and more prepared then the average bear if you subscribe to some security mailing lists.
Bugtraq mailing list. Not much noise and not Linux specific but good reading.
Full Disclosure mailing list. A lot of noise and higher volume but still has some good information.
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?
Linux zealots are going to run in defense of the [Linux] kernel.
Never let facts get in the way of a good rant:
To exploit any of these vulnerabilities an attacker needs control
over the answers of the connected smb server. This could be achieved
by man in the middle attacks or by taking over the smb server with
f.e. the recently disclosed vulnerability in Samba 3.x
While any of these vulnerabilities can be easily used as remote
denial of service exploits against Linux systems, it is unclear if
it is possible for a skilled local or remote attacker to use any of
the possible bufferoverflows for arbitrary code execution in kernel
space.
When all you have is a hammer, every problem starts to look like a thumb.
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!
all five exploits you listed are for old versions the exploitable programs. even the most recent one is 11 months old. Also, I've never had to worry about these remote exploits you listed. I simply have never used/installed any of the programs the exploits were for.
When looking at exploits for Linux systems, a lot of them are ones that you simply don't need to care about because you aren't using the specific software that's vulnerable. Also since it is possible run a Linux system without a single TCP aware service running, you can have a system that is impervious to automated attacks.
Of course, being impervious to worms doesn't mean impervious to viruses or trojans which, by definition, rely on the human to execute them.
Even the specific vulnerability in the kernel's smbfs module is rather limited in scope since it can't be used unless the target can be fooled into connecting to a malicious server.
If you don't look very hard, you won't find much. Even if you think you do.