Quick Take: Samba Vulnerability key data points
- Service: smbd
- Affected versions: 3.5+ (released at March 1, 2010)
- CVE: CVE-2017-7494
- CVSS v3 Score: 7.5
- Summary: Clients can upload and cause the smbd server to load a shared library
- Advisory link: https://www.samba.org/samba/security/CVE-2017-7494.html
About the Samba Vulnerability
In the last couple of days there was a lot of buzz about a new vulnerability. The bug, CVE-2017-7494, affects Samba, an open source implementation of Microsoft’s SMB/CIFS networking protocol, from version 3.5.0 and onwards.
The vulnerability allows an attacker to run an arbitrary code using a shared object which is loaded into Samba’s ‘smbd’ process. Assuming that one has an access to a remote share (either as guest or as an authenticated user), one can upload a shared object and then exploit the vulnerability to make ‘smbd’ service load it.
The crux of the bug lies in the implementation of the MSRPC (Microsoft RPC) protocol inside Samba service:
MSRPC protocol allows to connect to a named pipe from remote destination. When trying to open a pipe using MSRPC on Samba, the server verifies the validity of the pipe name using the internal function is_known_pipename().
An external RPC server can be set using the ‘rpc_server’ variable inside smb.conf and then it will handle the pipe request.
The function is_known_pipename() doesn’t check that the pipe is valid, this allows to use ‘/’ to insert a full path of an arbitrary library.
smb_probe_module() loads and invokes the pipe handler shared library init function.
A few days after the bug was found, Samba maintainers released a patch which fixed the pipe name validation inside is_known_pipename() (doesn’t allow usage of ‘/’ in the pipe name).
Exploitation and how Twistlock Responds to the Samba
I won’t get into details of exploitation of this bug because it was already addressed online. Instead, I’ll test how Twistlock responds to one of the possible exploits. I used a Docker container with the vulnerable Samba server for the test. The exploit will upload a malicious library to /data/ directory then instruct ‘smbd’ process to load it. The library will spawn a bind shell on 6699.
Twistlock has two different protection mechanisms against this vulnerability & payload. The first, our Vulnerability Scanner, checks the container’s packages list against a known list of vulnerable packages. Twistlock then will suggest to upgrade the package to the latest fixed version, if such version exists.
If you click on the package row, you will get detailed info about the CVE’s:
The second protection mechanism is Runtime Radar which learns the way a container is working, in terms of interaction with the disk and usage of syscalls, and then alerts (and if configured, blocks) the write to disk or the syscall.
After running the vulnerable Samba container for a while, Twistlock learned how ‘smbd’ process operates. Twistlock Runtime Radar recognized that ‘smbd’ process wrote the malicious shared library /data/libbindshell-samba.so to the disk and then recognized the syscalls that were used to initiate a bind shell process:
There are a lot of prior conditions to this attack which make it more difficult to exploit in the real world. Patches were released and soon all the distros will have the patched Samba service so that updating a container will become very easy. We are anticipating that IoT devices, which are usually not updated consistently, will continue to have this bug. Specifically NAS’es, routers (with USB port for external HD) and DVR’s. We’ll continue to keep you updated if there are significant updates to share.
Want more security alerts? Sign up for our blog newsletter or follow @TwistlockTeam on Twitter.
Breaking out of Docker via runC – Explaining CVE-2019-5736Read the Blog
T19 Challenge – Twistlock Lab’s first security challenge summary and solutionsRead the Blog
Kubernetes emergency survival: Hotfix patching running podsRead the Blog
Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)Read the Blog