Ugly Mitigation for Remote Code Execution Vulnerability in Samba

[anodos]

CVE-2017-7494: All versions of Samba from 3.5.0 onwards are vulnerable to a remote code execution vulnerability, allowing a malicious client to upload a
shared library to a writable share, and then cause the server to load and execute it.

The best solution is (of course) to update to the latest version of FreeNAS when it is released.

If for some reason, you are stuck on an old version of FreeNAS, setting the auxiliary parameter nt pipe support = no as an auxiliary parameter under Services->SMB mitigates the risk of this vulnerability. It may adversely affect windows clients that expect this functionality. I briefly tested on a Windows 10 client with standalone samba server (FreeNAS 11 VM). Setting this prevents clients from being able to connect to "\\server", but they are still able to connect to "\\server\share". Test before pushing it out on production machines. Note that code exploiting this vulnerability will be executed as root.

Source: https://bugzilla.redhat.com/show_bug.cgi?id=1450347#c3

P.S. setting all samba shares as "read only" also mitigates the problem.

 

[m0nkey_]

Maybe we can get push the devs to provide an update?

I did open a bug ticket yesterday: https://bugs.freenas.org/issues/24116

 

[Ericloewe]

A -U4 is planned.

 

[anodos]

Tested nt pipe support = no on FreeNAS configured as AD member server. It does not affect DCERPC over SMB2. Server stayed joined to domain. wbinfo -t succeeded. Null session connections don't work (IPC$ share). This is because the setting nukes ncacn_np support.

Code:

O:\>net view \\RIVENDELL
System error 5 has occurred.

Access is denied.

Guest access to the server is not affected.

Conclusion: it appears to be a safe parameter when Samba is configured in "standalone" and "ADS" roles, but you will lose the ability to enumerate shares on the server. You will also lose the ability to modify permissions within the share through the Windows File Explorer (because this is apparently also done over a named pipe).

 

[Ericloewe]

That would probably seriously impact the workflow of at least 50% of SMB users out there, but is doable.

 

[anodos]

That would probably seriously impact the workflow of at least 50% of SMB users out there, but is doable.

It won't affect people who have already configured permissions on their shares. It also won't affect people who have mapped network drives. BTW, it doesn't stop Linux clients from enumerating / browsing shares because Linux clients don't use named pipes for this purpose. People can always set permissions from the CLI, after all the syntax isn't that hard: find /path/to/share -type d -exec setfacl -m g:my_group:write_set:fd:allow {} \; :D