
Samba 3.5.0+ vulnerability: Remote code execution from a writable share - rivert
https://www.samba.org/samba/security/CVE-2017-7494.html
======
syvanen
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)

~~~
learntofly
Fix has also been pushed to Raspian (Debian for Raspberry Pi's)

Thanks to OP for highlighting this

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

------
mynewtb
Is this something new or ETERNALBLUE?

~~~
tyingq
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/02a76d86db0cbe79f...](https://github.com/samba-
team/samba/commit/02a76d86db0cbe79fcaf1a500630e24d961fa149)

~~~
benmmurphy
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
Ah, yes...I initially summarized the fix incorrectly. It's strchr(), so
disallows a pipe name with ANY slashes in it.

------
legulere
What's the vulnerability? C memory unsafety?

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

