4 ms·

Samba 3.5.0+ vulnerability: Remote code execution from a writable share

101 points by rivert 9y ago

mynewtb 9y ago
Is this something new or ETERNALBLUE?
- tyingq 9y ago
  Looks new. ETERNALBLUE was a buffer overflow, and not in Samba. This is Samba not restricting access to certain named pipes...the "IPC$ share" that can spawn processes. The fix disallows open on pipes with a name that starts with / : https://github.com/samba-team/samba/commit/02a76d86db0cbe79fcaf1a500630e24d961fa149 https://github.com/samba-team/samba/commit/02a76d86db0cbe79f...
  - benmmurphy 9y ago
    from what i gather they pass the pipename into smb_probe_module which ends up calling dlopen status = smb_probe_module("rpc", pipename); my guess is you can either pass in a pipename starting with / which will cause it to be treated absolutely or ../../ which will cause dlopen to do a relative lookup
    - tyingq 9y ago
      Ah, yes...I initially summarized the fix incorrectly. It's strchr(), so disallows a pipe name with ANY slashes in it.
- NetStrikeForce 9y ago
  This is Samba, not the Windows implementation of SMB.
legulere 9y ago
What's the vulnerability? C memory unsafety?
- benmmurphy 9y ago
  its a logic bug. they have some magic that loads modules at runtime based on a string a user supplies. but it doesn't take into account a user might be able to pass in / (i'm thinking absolute is probably not possible) or ../ which causes the module resolution to be done differently.
syvanen 9y ago
Info of fixed versions: Debian: https://security-tracker.debian.org/tracker/CVE-2017-7494 https://security-tracker.debian.org/tracker/CVE-2017-7494 Ubuntu: https://www.ubuntu.com/usn/usn-3296-1/ https://www.ubuntu.com/usn/usn-3296-1/ Red Hat: https://access.redhat.com/security/cve/CVE-2017-7494 https://access.redhat.com/security/cve/CVE-2017-7494
- HeadlessChild 9y ago
  That is really handy. Thanks for the info!
- learntofly 9y ago
  Fix has also been pushed to Raspian (Debian for Raspberry Pi's) Thanks to OP for highlighting this
- skarap 9y ago
  Note that SELinux mitigates the issue with default configuration.
ericfrederich 9y ago
So is this a RCE vulnerability that wouldn't be solved by using a memory safe language? Looks like a design issue and not an overflow or something.
- jra_samba 9y ago
  Yes. There are 2 subsystems involved: (1). Load a shared library module and execute it. This has many uses inside Samba. (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. A memory safe language would not have saved us here.

101 points by rivert 9y ago

mynewtb 9y ago

Is this something new or ETERNALBLUE?

tyingq 9y ago
Looks new. ETERNALBLUE was a buffer overflow, and not in Samba. This is Samba not restricting access to certain named pipes...the "IPC$ share" that can spawn processes. The fix disallows open on pipes with a name that starts with / : https://github.com/samba-team/samba/commit/02a76d86db0cbe79fcaf1a500630e24d961fa149 https://github.com/samba-team/samba/commit/02a76d86db0cbe79f...
- benmmurphy 9y ago
  from what i gather they pass the pipename into smb_probe_module which ends up calling dlopen status = smb_probe_module("rpc", pipename); my guess is you can either pass in a pipename starting with / which will cause it to be treated absolutely or ../../ which will cause dlopen to do a relative lookup
  - tyingq 9y ago
    Ah, yes...I initially summarized the fix incorrectly. It's strchr(), so disallows a pipe name with ANY slashes in it.
NetStrikeForce 9y ago
This is Samba, not the Windows implementation of SMB.

legulere 9y ago

What's the vulnerability? C memory unsafety?

benmmurphy 9y ago
its a logic bug. they have some magic that loads modules at runtime based on a string a user supplies. but it doesn't take into account a user might be able to pass in / (i'm thinking absolute is probably not possible) or ../ which causes the module resolution to be done differently.

syvanen 9y ago

Info of fixed versions: Debian: https://security-tracker.debian.org/tracker/CVE-2017-7494 https://security-tracker.debian.org/tracker/CVE-2017-7494 Ubuntu: https://www.ubuntu.com/usn/usn-3296-1/ https://www.ubuntu.com/usn/usn-3296-1/ Red Hat: https://access.redhat.com/security/cve/CVE-2017-7494 https://access.redhat.com/security/cve/CVE-2017-7494

HeadlessChild 9y ago
That is really handy. Thanks for the info!
learntofly 9y ago
Fix has also been pushed to Raspian (Debian for Raspberry Pi's) Thanks to OP for highlighting this
skarap 9y ago
Note that SELinux mitigates the issue with default configuration.

ericfrederich 9y ago

So is this a RCE vulnerability that wouldn't be solved by using a memory safe language? Looks like a design issue and not an overflow or something.

jra_samba 9y ago
Yes. There are 2 subsystems involved: (1). Load a shared library module and execute it. This has many uses inside Samba. (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. A memory safe language would not have saved us here.