[Info-vax] SAMBA and Ransomeware

[John E. Malmberg]

On 7/17/2017 2:13 PM, Michael Moroney wrote:
> kludge at panix.com (Scott Dorsey) writes:
> 
>> Our question, then, becomes this: How do we, knowing we have an inherently
>> untrustworthy protocol, manage to implement it in the safest possible way?
>> Because we have to implement it.  And we have to do it as safely as we can.
> 
> I suppose the VMS server process has as few privileges as absolutely possible,
> ideally TMPMBX+NETMBX only, if at all possible.
> 
> Naive question: Are the protocols fundamentally broken, security wise, or,
> in theory, could a good VMS programmer given the SMBx spec and no existing
> code as a bad example, write a secure SAMBA implementation from scratch?

While a lot of the SMB protocols are documented, there are likely things 
that are ambiguous or not specified.

And one of the thing to remember is the speed of the CPUs back when the 
earlier protocols were developed.

Turning on signing to prevent spoofing pretty much took all the CPU 
available once upon a time.

NTLM up to about Windows 7, is vulnerable to replay attacks by design.
Windows 7 added a place to register how trusted a host is for some NTLM 
traffic.

In the past, a LAN protocol did not need to be real secure, just good 
enough to prevent accidents.

There are other issues besides the protocol that need to be considered, 
Back in the Samba V4 development days there was quite a bit of 
discussion as to if it should be forked() like Samba V3, or threaded to 
be more like the Microsoft implementation.

The forked() model offered the advantages of the daemon running as the 
target user, and a program bug normally only caused a crash and to the 
user silent restart of that daemon.

The threaded model seemed to match how the messages in the protocol were 
actually sent and delivered to a server from a multi-user client.
And the proponents thought it might scale better.

It seemed to me at the time that the threaded implementation would fit 
VMS better.

Regards,
-John
wb8tyw at qsl.net_work