[Info-vax] SAMBA and Ransomeware

[johnwallace4 at yahoo.co.uk]

On Tuesday, 18 July 2017 16:41:46 UTC+1, Stephen Hoffman  wrote:
> On 2017-07-12 14:48:40 +0000, Neil Rieck said:
> 
> > I posted my worry about SAMBA a few weeks back but just noticed this 
> > blurb today.
> > 
> > https://www.theregister.co.uk/2017/07/11/hpe_stops_nonstop_server_samba_bugs/
> 
> Linux, too: 
> http://blog.trendmicro.com/trendlabs-security-intelligence/linux-users-urged-update-new-threat-exploits-sambacry/ 
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Further Linux-centric reading following on from trendmicro's
article can be found at e.g.
https://access.redhat.com/security/cve/cve-2017-7494 (Red Hat extract below)
and in a StackExchange discussion at
https://unix.stackexchange.com/questions/367138/wannacry-on-linux-systems-how-do-you-protect-yourself


This vulnerability appears to derive from (oversimplified)
allowing remote Samba users to write shareable libraries to 
writable Samba shares, and then allowing those sharable 
libraries to be invoked by remote users, perhaps executing 
them with elevated privileges.

Sensible DECnet/FAL users on VMS were encouraged to stop 
permitting that kind of thing a couple of decades ago 
(actually, probably more). Obviously it was in the context 
of FAL not Samba but the remote access/untrusted code 
parallels and principles perhaps need to be re-invented.

Don't execute untrusted code, especially with privileges, 
even more so when the code is in some remotely writable
location and is invoked via some remote access mechanism 
with limited authentication. 

A shared library in a semi-public upload directory might
contain untrusted code; might be safest to assume it does. 
Tread carefully.

It's not rocket science, but it appears to be new to 
some people who perhaps should know better. 

RedHat's default SELinux policy seems to do the right 
thing.

Corrections and clarifications welcome.

..............

Highlights from the RedHat article at
https://access.redhat.com/security/cve/cve-2017-7494
"A malicious authenticated samba client, having write 
access to the samba share, could use this flaw to execute 
arbitrary code as root.
[...]
Mitigation

Any of the following:

1. SELinux is enabled by default and our default policy prevents loading of modules from outside of samba's module directories and therefore blocks the exploit

2. Mount the filesystem which is used by samba for its writable share using "noexec" option.

3. Add the parameter:

    nt pipe support = no

    to the [global] section of your smb.conf and restart smbd. This prevents clients from accessing any named pipe endpoints. Note this can disable some expected functionality for Windows clients.
"