Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Bug Open Source Security Networking Linux

Wormable Code-Execution Bug Lurked In Samba For 7 Years (arstechnica.com) 83

Long-time Slashdot reader williamyf was the first to share news of "a wormable bug [that] has remained undetected for seven years in Samba verions 3.5.0 onwards." Ars Technica reports: Researchers with security firm Rapid7...said they detected 110,000 devices exposed on the internet that appeared to run vulnerable versions of Samba. 92,500 of them appeared to run unsupported versions of Samba for which no patch was available... Those who are unable to patch immediately can work around the vulnerability by adding the line nt pipe support = no to their Samba configuration file and restart the network's SMB daemon. The change will prevent clients from fully accessing some network computers and may disable some expected functions for connected Windows machines.
The U.S. Department of Homeland Security's CERT group issued an anouncement urging sys-admins to update their systems, though SC Magazine cites a security researcher arguing this attack surface is much smaller than that of the Wannacry ransomware, partly because Samba is just "not as common as Windows architectures." But the original submission also points out that while the patch came in fast, "the 'Many eyes' took seven years to 'make the bug shallow'."
This discussion has been archived. No new comments can be posted.

Wormable Code-Execution Bug Lurked In Samba For 7 Years

Comments Filter:
  • NT Pipe Support? (Score:4, Interesting)

    by Dwedit ( 232252 ) on Saturday May 27, 2017 @12:42PM (#54497985) Homepage

    What exactly is NT Pipe Support supposed to even do? Why would you need it on a file server?

    • I tried disabling it, and immediately got calls from people that 'a trust relationship can't be established with the central logon server' or some such thing when they tried to log in.
      • Re:NT Pipe Support? (Score:4, Informative)

        by williamyf ( 227051 ) on Saturday May 27, 2017 @01:42PM (#54498233)

        Submitter here.

        From the SUMARY: "The change will prevent clients from fully accessing some network computers and may disable some expected functions for connected Windows machines."

        So, it seems that your connected Windows machines use the expected functions that the setting disables.

        Go figure.

        Good though to know one of the error messages that may arise after turning of the setting.

      • Instead of that setting, you can also mount the filesystem for the samba shares using the noexec option. Not sure if that also impacts windows access, though.

        Some SELinux configurations, such as on RHEL/Centos will prevent this too. "SELinux is enabled by default and our default policy prevents loading of modules from outside of samba's module directories and therefore blocks the exploit." For people more affected by it, copying the SELinux configuration might be the best short term option, though it is a l

    • Re:NT Pipe Support? (Score:4, Informative)

      by Sperbels ( 1008585 ) on Saturday May 27, 2017 @01:03PM (#54498065)
      It's a setting that turns on/off the ability to make anonymous connections to the windows IPC named pipes service.
    • Re:NT Pipe Support? (Score:5, Informative)

      by thegarbz ( 1787294 ) on Saturday May 27, 2017 @02:31PM (#54498437)

      From the manual:

      nt pipe support

      This global option is used by developers to allow or disallow Windows NT/2000/XP clients the ability to make connections to NT-specific SMB IPC$ pipes. As a user, you should never need to override the default:

              nt pipe support = yes

    • I have an Archer router which mounts a USB disk and servers it by SMB connection. I'm not skillful enough to know how to look at the router's intimate details. But I would like to know if it's suceptible to this bug. Is there a way one can test this from outside the device?

  • by green1 ( 322787 ) on Saturday May 27, 2017 @12:46PM (#54497997)

    I think you'd find the risk can be mitigated significantly by simply not allowing Samba to connect to the Internet, I can't think of any reason why you'd do that anyway. It's designed for local resource sharing, not Internet transfers.

    • by TheRaven64 ( 641858 ) on Saturday May 27, 2017 @02:10PM (#54498339) Journal
      Unfortunately, it just takes one compromised machine entering your network for that to be an issue. If someone leaves it enabled on their laptop at some open WiFi access point, gets infected, and then connects to your corporate network, then a worm can propagate. Fortunately, there probably aren't enough machines running Samba (macOS switched to Apple's own CIFS implementation since Samba went GPLv3) for it to be easy to propagate (though if someone combined it with the recent Windows SMB vulnerability, then you'd have an interesting worm).
      • It can let an attacker move laterally in your network. The "But it is behind a firewall I don't have to worry," is not good security. Someone gets in to your network they are behind the firewall and can make use of it. So they do something like get on to a user's workstation because said user is a dope who will click anything. Ahh but you aren't worried, after all said user doesn't have access to any important data, isn't a local admin and is running Windows. All the important Linux stuff is safe. ...howeve

    • I can't think of any reason why you'd do that anyway


  • This is a classic slashdot dupe.
    https://it.slashdot.org/story/... [slashdot.org]

  • by williamyf ( 227051 ) on Saturday May 27, 2017 @01:53PM (#54498277)

    Submitter here.

    I've been following this with a lot of attention. (here is The Register's take on the matter, by the way: https://www.theregister.co.uk/... [theregister.co.uk] )

    And I, as many other commenters, think that the real problem is not on linux servers or Workstations with supporrted distros, for which patches already exist, but rather, on many Abandoned Distros, many cheapo NAS boxes, home Routers, IoT stuff and other dohickeys that use Linux on their firmware behind the scenes. I've a synology DS1515+ in my lab at home, and the bug was squashed on may 25, but the fix has not yet propagated to my NAS via automatic updates, but at least there is a fix (and no, SMB is not open to the Internet).

    Now, think of those cheapo NAS boxes that do not see a firmware update in years, or those routers with a USB port in the back to slap a USB HDD and "share files effortlessly", or Distros like one of my old time favourites Damn Small Linux. Those are likely So Out of Luck...

    No, I do not think this will be a SaMBaPOCALIPE, but I will be bad for some people.

    • How can I test my NAS? I have no way to look at it's internals. But maybe there is an external way to do this (e.g. run the worm?)

      • Submiter here:

        You can use metasploit, which already has incorporated this bug.

        From the article on "El'Reg"

        "Re: Samba bug, the metasploit one-liner to trigger is just: simple.create_pipe("/path/to/target.so")"

        • I just contacted TP-Link the maker of Archer routers. They claim that they use Linux but they do not use SAMBA. I'm skeptical. Is there something other than SAMBA for doing SMB communications on Linux?

    • Still an attacker needs access to a account on your samba share with write access because he needs to first upload a library with his payload and then tell samba to execute it.
    • Nothing really is out of luck. These machines should not be exposed to the wider internet. People who are stuck in a situation where this affects them should look in general at their network management rather than this specific bug.

      NASes and similar should be internal to the network.
      Routers which are exposing samba to the wider internet ... well let me say I'm not concerned about the samba bug but rather the entire device itself. Those "share files effortlessly" on the WAN side should never be doing it via

      • Submitter here:

        Even if machines or NASes are internal to the network, someone may send you a boobytrapped email or webpage, and infect the suceptible machines from INSIDE the network, sort of like one of the modes of contagion from the WCry worm

        • If you can write an email to either automatically do or manually convince a user to upload a specially crafted payload to a writable share, no amount of patching it going to render that network safe.

          This is orders of magnitude harder to do from outside the network as you require knowledge of the network setup itself. Then you need to craft an attack specific to that network, and then you need to get the user to fall for that attack. Too hard, just get a user to type in his bank details into a phishing site

          • by xvan ( 2935999 )
            Assuming you earned limited access to a private network, you can use this bug to escalate privileges.
            • Which brings me back to my original comment: Bug mostly defeated by network design which reduces its severity by orders of magnitude.

  • by Anonymous Coward

    Note that SELinux stops this vulnerability in default configuration.

    • by Anonymous Coward

      ayy lmao
      and introduces how many others?

  • That's not what the quote about many eyes means!

    It doesn't mean that bugs are magically found in open source software. It means that when bugs are found, the cause is generally located quickly because it makes the bugs appear shallow (easy to fix) not deep.

  • by Anonymous Coward

    Check this link for a description of SambaCry


  • But the original submission also points out that while the patch came in fast, "the 'Many eyes' took seven years to 'make the bug shallow'." How many years would the bug persist if only a few eyes were looking at the code?
  • Why would anybody expose a Samba server to the internet?
    • you usually don't. But once this thing gets trojaned onto one computer on an intranet, it worms the whole thing.

  • Two things here:

    1. It's more applicable to once a bug is known than to finding new bugs.

    2. Even then it still fails though, as there was a bug in BSD readdir for nearly 25 years. Samba developers had coded around the bug rather than try to fix it. See http://www.osnews.com/story/19... [osnews.com]

  • because Samba is just "not as common as Windows architectures.

    There are a *lot* of NAS devices out there running linux with default SMB shares. Updates take some time for them to be prepared - if they are at all. Even longer for them to be installed by users - if they are at all.

    Worse, there are probably even more MFD's (Copy/Scan/Print/Fax) devices in every business, corporate, enterprise etc. And they almost all run embedded linux with Samba and default shares, for document storage, scans, secure print etc. And they will almost never be updated - Canon, Ricoh, Xerox

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller