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."

Comments

history of linux exploits

[wrinkledshirt]

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?

But...

[Sensible Clod]

does it allow ROOT?

Re:But...

[Sensible Clod]

Come on, I really want to know whether this allows someone to take over my machine. Besides, as an M$ hater, I want to be able to tell people 'hey, the linux kernel exploit *doesn't* allow root'. Unless, of course, it does. Does it?

Re:But...

[Nothinman]

It's a bug in a kernel driver, so if it becomes exploitable it could allow more than root. But from the looks of the report, you would have to mount a share on the attacking machine for there to even be a chance of exploitation.

And before this goes off the front page...

[Short Circuit]

Major distributions will have patches available. Possibly even the main kernel tree.

Re:And before this goes off the front page...

[DraconPern]

Red Hat 9 is a 'major distribution' and I haven't had a kernel patch in ages. My box is probably venerable to all sorts of bugs. But now Red Hat wants me to pay for security updates? Grrr. 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.

Timeline...

[AcornWeb]

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?

Does this apply to FreeBSD?

[HenryKoren]

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

53 day turnaround, is that good?

[JAFSlashdotter]

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?

Re:53 day turnaround, is that good?

[Nothinman]

I wouldn't say it's a good turnaround, but considering that SMB is one of the hairiest protocols around and SMBFS has been deprectated in the hopes of the CIFS driver taking it's place, it's not hard to imagine that it would take a while to find someone knowledgable enough and willing to track down each of those problems.

Re:Everyone makes mistakes

[Truth_Quark]

"this is some proof that micro$oft isn't the only place in the world that puts out code with security holes"

This kind of comment disturbs me. I never know how far down the conspiracy theory line I should allow my paranoia to run. The statement is prima facie true, so what requirement is there for such proof except to Microsoft FUDrakers?

Is microsoft paying people to post their marketing crap like this, or is it merely that trolling is its own reward?

Re:NOT Originally MS Technology

[kmb]

Oh, yes, Microsoft could take a rock-solid protocol/standard/technology and break it, easily. It's probably equally possible that SMB has become more secure or less secure in Microsoft's hands. However, I was correcting the widespread factual error of "Microsoft invented SMB." Microsoft doesn't even call their implementation SMB anymore. It's CIFS now.

I don't know much about this specific bug, but c'mon people, there have been linux security bugs concerning technologies and protocols Microsoft hasn't managed to put their grubby little fingers into. There are enough valid complaints against them to keep us from having to start making them the de facto scapegoat.

Of course, if Microsoft were to be believed, they really do own all the protocols.

Re:MS Technology

[CAIMLAS]

First off, as someone else said, this doesn't have anything to do with Samba, but smbfs.o, from the kernel. You don't need smbfs.o to use samba, I believe, and I can't recall ever including it in a kernel (or cifsfs), even ones that were to be used as a samba fileserver.

Second, NFS is just as "full of holes" as SMB/CIFS. I'd even wager that its inherrent security model is worse. From my experience, it's also significantly less stable, and does not scale well at all, let alone dynamically on a large network.

On a network where everyone is a peer, SMB/CIFS seems like the better option to me.

Re:I'm glad this hit slashdot

[CAIMLAS]

Well, if you give it a little thought, it makes sense on a purely logical level.

SMB is the protocol used pre-win2k. CIFS is everything after that. It makes little sense to modify (or expect) a device driver to support something that is outside the scope of it's designed purpose. Thus, along came cifsfs, which does indeed support the higher features (and very well might not work in a 'backward compatible' fashion, for all I know). Thus, you wouldn't need both if you didn't have any newer|older windows systems.

Re:MS Technology

[Lost Race]

I use Samba+SMBFS to share read-only trees with multiple filesystems mounted in them. NFS can't really handle this, at least not reliably. For this purpose SMB works well enough. Is there something better?

It's 2004, and there's no excuse

[billstewart]

I took Computer Science 101 back in 1974, and the first couple of lessons we learned were

• 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.

Re:It's a FEATURE

[Anonymous Coward]

Funny you should say that, as most of my (test) kernel crashes used to occur precisely when using smbfs..

I think I'm immune

[ajs318]

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.