Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Software Linux

Security Flaws In Linux SMBFS 347

Posted by timothy from the or-would-you-rather-wait-for-service-pack-n dept.
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."
This discussion has been archived. No new comments can be posted.

Security Flaws In Linux SMBFS More

Security Flaws In Linux SMBFS

Comments Filter:

  • It's a FEATURE (Score:5, Funny)

    by kesuki ( 321456 ) on Monday November 22, 2004 @07:16PM (#10893558) Journal
    you haven't emulated SMB unless you allow remote execution of code ;)

  • history of linux exploits (Score:3, Interesting)

    by wrinkledshirt ( 228541 ) on Monday November 22, 2004 @07:17PM (#10893565) Homepage
    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... (Score:2, Interesting)

    by Sensible Clod ( 771142 )
    does it allow ROOT?

    • Re:But... (Score:3, Interesting)

      by Nothinman ( 22765 )
      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.

    • Re:But... (Score:4, Insightful)

      by EvilAlien ( 133134 ) on Monday November 22, 2004 @09:07PM (#10894420) Journal
      You don't need root, you just need local access so you can exploit all those vulnerabilities that get ignored because they aren't remotely exploitable.

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

  • this is NOT samba (smbd) (Score:5, Informative)

    by CRC'99 ( 96526 ) on Monday November 22, 2004 @07:17PM (#10893572) Homepage
    It should be clarified, that this is NOT to do with the smbd process aka Samba Project - but the kernel module smbfs.o
  • 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.

    • No shiat. (Score:2, Insightful)

      by bersl2 ( 689221 )
      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.
    • Well, not to sound like a broken record, but you can bet your sweet ass that the smbfs module code will be fixed quicker than you can say rmmod, or if you prefer, quicker than you can say "make dep clean bzImage modules modules_install".

      The difference is the opportunity to take action through the utilization of an openly available codebase.

    • Re:Everyone makes mistakes (Score:5, Insightful)

      by 13Echo ( 209846 ) on Monday November 22, 2004 @08:06PM (#10894029) Homepage Journal
      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.
    • "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?

    • This is one reason a microkernel OS can be more secure and robust. When shit breaks loose the kernel is still isolated.
    • I think the difference here is that this exploit is likely to be fixed within a six month time span.
    • 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 sec

  • yeah ... (Score:3, Funny)

    by nanodude ( 826755 ) <(moc.liamg) (ta) (7595yticolev)> on Monday November 22, 2004 @07:18PM (#10893579)
    well ... windows file sharing is just that ... a security flaw

  • Hmmm..... (Score:2, Funny)

    by Azh Nazg ( 826118 )
    Makes me glad that I have an SMB block enforced on my rou32der324f[NO CARRIER]

  • MS Technology (Score:4, Informative)

    by Punboy ( 737239 ) * on Monday November 22, 2004 @07:19PM (#10893593) Homepage
    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.

    • NOT Originally MS Technology (Score:5, Informative)

      by kmb ( 56194 ) on Monday November 22, 2004 @07:49PM (#10893915)
      Microsoft did NOT in fact invent/originate SMB. IBM did. [wikipedia.org]
    • On the other hand, many people need to use it in their home networks to share files between windows machines and Linux machines.
      Freely available Cross platform alternatives for file sharing include FTP, GNUTELLA, and a host of other lesser known protocols. FTP was what I used, a server dameon on my *nix box, and depending on what I was doing either some freeware client on windows, or else the good old ftp.exe. which was BSD license code that windows used because 'It was BSD License, and was one less thing

    • Re:MS Technology (Score:2, Insightful)

      by Anonymous Coward
      So which is worse: implementing a technology that turns out to have security holes or adding a technology you already know has security holes to your system in order to be compatible with a system you claim is inferior?

    • Re:MS Technology (Score:5, Insightful)

      by nacks1 ( 60717 ) on Monday November 22, 2004 @08:10PM (#10894049) Homepage Journal
      "Most Linux-only users use NFS, which does not have these security holes."

      Yeah... it NFS just has plenty of holes of its own. I would be the first to say that I think that SMBFS is crap, but NFS isn't the network filesystem that we should be holding up as a good system to emulate.

      • Re:MS Technology (Score:2, Informative)

        by mre5565 ( 305546 )
        > Yeah... it NFS just has plenty of holes of its own.

        NFS uses ONC RPC. ONC RPC supports any security
        flavor the ONC RPC library implementor choses.
        RFC 2203 is an security flavor that supports
        GSS-API, which works over Kerberos and
        Public Key Infrastructure. Solaris, AIX, NetApp,
        EMC, Hummingbird have NFS/Kerberos via RFC 2203.
        The bits are sort of there in Linux 2.6, and
        should be there for when Red Hat and Suse release
        enterprise editions of Linux 2.6.

    • Re:MS Technology (Score:4, Interesting)

      by CAIMLAS ( 41445 ) on Monday November 22, 2004 @08:42PM (#10894241)
      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.
    • "Most Linux-only users use NFS, which does not have these security holes."

      RPC (NFS runs over RPC) vulnerabilities have been among the most numerous over the years, and NFS security sucks even apart from that.

    • Re:MS Technology (Score:5, Informative)

      by geg81 ( 816215 ) on Monday November 22, 2004 @08:51PM (#10894316)
      Most Linux-only users use NFS, which does not have these security holes.

      Are you kidding? From a security point of view, past versions of NFS have been an absolute disaster, far worse than SMB. You can run NFS only if you have complete trust in your network infrastructure and every single machine on it. Sun's engineers must have been on drugs when designing it.

      NFSv4 may fix some of those problems, but it hasn't been widely deployed yet, and it is far more complex than it has a right to be given its limited functionality. All network file systems for Linux currently have major problems of one kind or another (they are one of incompatible, immature, insecure, etc.).

      • Re:MS Technology (Score:3, Insightful)

        by sloth jr ( 88200 )
        No particular beef with your post - as you mention, NFS security isn't good. Put another way, it's as good as your network and host security, but relies on proper configuration of server and client. That said, NFS for being the pile of shit it is has survived through virtue of being widely supported and mostly compatible, robust in the face of server outages (as opposed to SMB's "oh, I guess you'll be losing the latest copy of your work now"), easily clusterable, scalable to several dozen busy clients, easy

    • ERROR! (Score:2, Funny)

      by DAldredge ( 2353 )
      ERROR DETECTED

      REASON - NFS used with in 10 words of the word secure.

      RESULT - AHHHH!!!!

    • Re:MS Technology (Score:3, Interesting)

      by Lost Race ( 681080 )
      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?

  • And before this goes off the front page... (Score:4, Interesting)

    by Short Circuit ( 52384 ) * <mikemol@gmail.com> on Monday November 22, 2004 @07:19PM (#10893597) Homepage Journal
    Major distributions will have patches available. Possibly even the main kernel tree.

    • Re:And before this goes off the front page... (Score:5, Informative)

      by Alan Hicks ( 660661 ) on Monday November 22, 2004 @07:30PM (#10893745) Homepage
      <spamvertisement>
      This is old news. The 2.4.28 kernel was released with fixes for this though a 2.6.10 kernel hasn't yet been put out. I'm not sure who all has patched, but for Slackware users, you can get a 2.4.28 kernel package from SlackSec [slacksec.info].
      </spamvertisement>

      • that'd be fine if new kernels didn't break you... (Score:2, Informative)

        by Anonymous Coward
        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?
    • 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.
      • Try Debian and stop yer bitching
      • Actually, RedHat 9 updates are still available through the Fedora Legacy project (http://www.fedoralegacy.org/ [fedoralegacy.org]). Payment not required (though I'm pretty sure they'd like a donation or two)
      • Red Hat 9 is not a "major distribution". It is no longer supported. Just as Win 3.1/95 is no longer a "major" version of MS Windows. You can get that 5 year support from Red Hat through there Red Hat Enterprise Desktop. If you think RH is too expensive (like I do), try SuSE or Fedora or Mandrake or Debian or etc.

        Red Hat != Linux

      • Venerable, adj.
        1. Commanding respect by virtue of age, dignity, character, or position.
        2. Worthy of reverence, especially by religious or historical association: venerable relics.
        3. Venerable Abbr. Ven. or V.
        1. Roman Catholic Church. Used as a form of address for a person who has reached the first stage of canonization.
        2. Used as a form of address for an archdeacon in the Anglican Church or the Episcopal Church.

        Ignoring parts of speech for a moment, that makes for a pretty f
        1. 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.

        Then just update what you want. Nothing is stopping you.

        If you can't figure out how, get apt and Synaptic...run Synaptic, and update.

  • I'm glad this hit slashdot (Score:5, Informative)

    by Anthony Liguori ( 820979 ) on Monday November 22, 2004 @07:21PM (#10893628) Homepage
    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 [mirror.bit.nl]. 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.

    • Re:I'm glad this hit slashdot (Score:4, Funny)

      by Anonymous Coward on Monday November 22, 2004 @07:29PM (#10893739)
      CifsFS

      This message was brought to you by the department of redundancy department.
    • This (parent)notice should be added to the headline as a public service.

    • Re:I'm glad this hit slashdot (Score:4, Informative)

      by Dr.Dubious DDQ ( 11968 ) on Monday November 22, 2004 @07:40PM (#10893835) Homepage

      The only downside that I have seen to using CIFS is that - at least on Slackware - mount.cifs doesn't seem to be included by default.

      It's trivial to obtain, but kind of difficult to mount CIFS filesystems without it...

      Note also that the old SMBFS is subject to the annoying 2GB file size limit, while CIFS is not, if you still need an excuse to switch. As far as I can tell, you can use CIFS for any server where you would previously have been using SMBFS, so you ought to be able to just switch without any hassles.

    • Re:I'm glad this hit slashdot (Score:4, Informative)

      by C3ntaur ( 642283 ) <panystrom@gmai l . c om> on Monday November 22, 2004 @07:53PM (#10893943) Journal
      I don't know about other distros, but when I tried to use CIFS to mount in Fedora Core 2 instead of SMBFS, I got a bunch of kernel errors. AFAIK, it's still an open bug: bugzilla.redhat.com [redhat.com].
    • Hmm. Might that be why I have problems connecting to Windows 2003 shares, where I previously had no problems a few years ago (with Samba)? I've run mount smbfs through the ringer a million times, where it used to be pretty simple, and now get all sorts of weird errors from the servers that carry the shares.

    • smbfs -> cifs is easy (Score:5, Informative)

      by xant ( 99438 ) on Monday November 22, 2004 @08:50PM (#10894306) Homepage
      I had one Linux server mounting smbfs shares from fstab on my network, running Ubuntu. The default kernel is 2.6.x and mount.cifs is included, so I found it extremely easy to convert.

      1. I was using the credentials option (-o credentials=/some/sekrit/file) and I discovered that cifs does not like spaces in this file, so I took out the spaces.
      2. I was also using the badly-named fmask and dmask options (they are not masks). Cifs has renamed these to dir_mode and file_mode, and deprecated the old usage. I renamed dmask to dir_mode and fmask to file_mode.
      3. file_mode and dir_mode expect to see a leading 0 to be interpeted as octal. I made this change.
      4. Finally I changed smbfs to cifs.

      After these minor changes that took me all of 3 minutes to make, I no longer have smbfs anywhere on this network.
    • It seems to be more stable as well. The share mount with my mp3s would freeze up every few hours of steady use with Beep/XMMS. CIFS Just Works.

  • The link doesnt actually tell you anything (Score:5, Informative)

    by Laeraun ( 183590 ) on Monday November 22, 2004 @07:21PM (#10893630) Homepage
    This page [securityfocus.com] gives a much better overview of what it is.

    More information also here [securityfocus.com]

  • Don't worry! (Score:5, Funny)

    by Tezkah ( 771144 ) on Monday November 22, 2004 @07:24PM (#10893666)
    SP2 users are unaffected.
  • SecurityFocus says, "The vendor has released version 2.4.28 of the Linux kernel to address these issues."

  • Timeline... (Score:3, Interesting)

    by AcornWeb ( 770294 ) on Monday November 22, 2004 @07:31PM (#10893756) Homepage
    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?

    • Re:Timeline... (Score:3, Informative)

      by mnmn ( 145599 )
      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.

      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. ..except theres no

  • Does this apply to FreeBSD? (Score:3, Interesting)

    by HenryKoren ( 735064 ) on Monday November 22, 2004 @07:33PM (#10893779) Homepage
    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

  • Now... (Score:3, Insightful)

    by bogaboga ( 793279 ) on Monday November 22, 2004 @07:34PM (#10893786)
    ...Linux zealots are going to run in defense of the [Linux] kernel. Come on guys, anything created by man will always have defects.

    Cb..

    • "anything created by man will always have defects."

      As opposed to that made by code monkeys?
    • No way. I'm root. Everything I do is perfect. What was your username again?
    • Come on guys, anything created by man will always have defects.

      That which is created by woman, on the other hand...

    • Re:Now... (Score:3, Informative)

      by Tough Love ( 215404 )
      Linux zealots are going to run in defense of the [Linux] kernel.

      Never let facts [securityfocus.com] 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 uncl
  • Based on the info http://www.securityfocus.com/archive/1/381420 [securityfocus.com]here, 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?

    • Really a two-part turnaround (Score:4, Informative)

      by Cerlyn ( 202990 ) on Monday November 22, 2004 @08:01PM (#10893995)

      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.

    • 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.
  • I'm switching back to Windows XP! Heck, Windows won't even allow users the choice of using all these insecure file systems! Now that is security!

  • Why not use webdavs or sftp? (Score:3, Informative)

    by Ambassador Kosh ( 18352 ) on Tuesday November 23, 2004 @01:01AM (#10895768)
    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.

  • I think I'm immune (Score:3, Interesting)

    by ajs318 ( 655362 ) <sd_resp2NO@SPAMearthshod.co.uk> on Tuesday November 23, 2004 @04:59AM (#10896541)
    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.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close