back to article Fat-thumbed dev slashes Samba security

Sysadmins tending Samba need to get patching. Samba's announcement, here, explains that it's suffering from a remote code execution bug that applies to all versions newer than Samba 3.5.0. The software, currently at version 4.6.4, provides *nix integration with Windows file and print services. In CVE-2017-7494, a malicious …

  1. Flocke Kroes Silver badge

    Correction in the comments:

    No regexes. The problem was that the path separator character ('/' in unix) should not have been allowed in pipe names. The '\' is a part of '\n' (new line) in debugging output. The new code is:

    if (strchr(pipename, '/')) {

    DEBUG(1, ("Refusing open on pipe %s\n", pipename));

    return false;

    }

  2. Neil Barnes Silver badge

    Interesting...

    My mint machines got a samba update last night/this morning - is this the fix for the issue or something else? It wasn't listed as #1 critical.

    1. jake Silver badge

      Re: Interesting...

      Easy enough to find out. Read this page. Compare and contrast your system's version numbers with the patched version numbers on that page. Command line to check yours is a simple samba --version.

      1. bob, mon!

        Re: Interesting...

        Annoyingly, the listed patches are for Samba 4.6, 4.5, 4.4, and some 3.x versions. My just-updated Ubuntu 16.04 LTS system is using Samba 4.3.11 --- I had to go into the changelog to verify that this version is in fact the patch for CVE 2017-7494. Done on May 19, BTW.

        1. gerdesj Silver badge
          Linux

          Re: Interesting...

          Just to spell it out for Debian and derivatives, this will spit out the precise version installed:

          $ apt-cache policy samba

          Check eg here: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-7494.html

  3. John Smith 19 Gold badge
    Unhappy

    Something tells me this is not the first time this has been found.

    But I'm not sure who by.

    1. Anonymous Coward
      Anonymous Coward

      Re: Something tells me this is not the first time this has been found.

      Not Sure Actually

    2. Anonymous Coward
      Anonymous Coward

      It went unnoticed for seven years...

      ... actually it looks not many people get asleep by reading open source code....

  4. CAPS LOCK Silver badge

    Carter will be along shortly to explain how this was missed...

    ... I wonder what she/he will say?

  5. Mage Silver badge

    Mitigation

    No one is silly enough to port forward so samba shares are on on the Internet. Except maybe NHS, but do they run any Linux servers?

    Obviously any computer on the LAN, if not properly secured, could be used to mount an attack.

    1. phuzz Silver badge
      Happy

      Re: Mitigation

      "No one is silly enough to port forward so samba shares are on on the Internet."

      Ahahaha, hahaha, ahahaaa. You're kidding right?

      A quick search on Shodan finds half a million, and that's just on port 445.

      Remember, someone is always stupid enough to do anything you can think of.

    2. This post has been deleted by its author

  6. david 12

    Not a bug, that's a feature!

    But it doesn't obviously make sense. A Samba client should be calling CreateFile or TransactNamedPipe or CallNamedPipe. A Samba server should support those calls.

    Assuming that the server accepts "CreateFile" for a named pipe that is actually the name of an executable, and that pipes are implemented at the server end through the same mechanism as file access, it should be doing CreateFile, not Execute File.

    And "CallNamedPipe", in spite of the slight ambiguity of the name, is supposed to Call the Named Pipe, not Call the OS. That is, it is supposed to read and/or write to the Pipe/File. Again, why would reading or writing a file at the server cause it to execute?

    On the face of it, it looks like there might be deeper problems that are being fixed in the short term with a quick simple patch?

    1. Jeremy Allison

      Re: Not a bug, that's a feature!

      > On the face of it, it looks like there might be deeper problems that are being fixed in the short term with a quick simple patch?

      No, that's not the case. I did the forensics on this.

      There are 2 subsystems involved here.

      (1). Load a shared library module and execute it.

      This has many uses inside Samba, plugin VFS libraries etc.

      (2). Allow a client request on an RPC pipe to be routed to an external process or library.

      This allows Samba to be built without embedding all the named pipe services inside it, which makes it a smaller binary for embedded vendors.

      Unfortunately an old commit connected the two subsystems together, re-using the shared library module existing code to find and load the service the client was asking for. There was insufficient sanitization of the requesting name which caused the problem. That's what the fix now does.

      In the future more restrictions are planned (along with cmocka regression tests) to improve the code quality here.

      1. Ramazan

        Re: an old commit connected the two subsystems together,

        Jeremy, are you one of SAMBA devs? Loading plugins must be

        1. restricted to a known list of "trusted" plugins

        2. list of trusted plugins must be configurable by server admin

        3. list of trusted plugins must be empty by default

        4. libraries must only be loaded from trusted paths /usr/lib and /lib

        5. user input must never get into parameters of dlopen() or into "trusted" plugins or paths lists

        6. user input should never get into parameters of execve(), too long to explain in details here

        1. Jeremy Allison

          Re: an old commit connected the two subsystems together,

          Yes I am fully aware of these restrictions and the reasons for them, and Samba follows these in all of our internal library code. Plugins are only loaded from $SAMBA_INSTALL_BASE_DIR/lib/<subsystem_name>/plugin_name.so where <subsystem_name> is hard coded at compile time.

          The bug occurred because this was connected to the RPC subsystem, which originally had a hard-coded list of acceptable plugin names (that's why the pre-3.5.0 code is not vulnerable), but this was relaxed for 3.5.0 and above - which was a big mistake. We will be correcting that in future releases, but due to the severity of the problem and immediacy of the threat we decided we had to go with the minimal secure patch for the CVE release.

  7. TheVogon

    So this is going to effect home routers with file serving capabilities too then? Ouch. Sounds very wormable.

    1. Danny 14

      NAS drives too, some Seagate offerings had internet facing options. I doubt they will have patches or people know how to SSH.

    2. TheVogon

      Synology have now issued a patch for their kit.

  8. Ramazan
    Facepalm

    So, they removed the slash/path traversal, but SAMBA can still do simple.create_pipe("foobar.so")? Imbeciles...

    You know, loading arbitrary .so or .ko files even from a trusted path is not a good idea. In case you didn't know, grsec recommends to disable loading of additional modules into kernel after initrd/system boot phase is complete. The same is true for unnecessary shared libraries.

  9. Griffo

    Now if this was in windows

    So a bug in the SMB handler that allowed for remote compromise, and has been there for what, 7 years?

    Now if this was a Microsoft piece of software, this forum would be full of people pissing and moaning about Microsoft, decrying closed source software, and claiming this stuff never happens in open source, blah blah blah.

    Funny aint it. All software truly does have bugs.

    1. Trixr

      Re: Now if this was in windows

      Totally agree. So far it's mostly "oops, here's a workaround, hope you guys fix it soon", rather than rants about "Linu$$$" and "Tridge-hell" and the like.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020