[vlc-devel] [PATCH] smb: try libdsm first

Rémi Denis-Courmont remi at remlab.net
Wed Oct 16 19:43:38 CEST 2019

Le keskiviikkona 16. lokakuuta 2019, 14.29.01 EEST Simon Latapie a écrit :
> The man-in-the-middle attack on a samba server is, as I said, completely out
> of scope of this patch. On that subject, if you have a solution or
> suggestion, please share it.

The solution is easy, well known, and well documented: refuse to negotiate the 
old protocol. In some specific cases like TLS there may be better ways. In 
general, and in the case of SMB1, there are not.

It's not an accident that even Microsoft very very very strongly advises to 
turn SMB1 off, and dropped support for it in recent Windows versions.

> Sorry but I still do not understand where the second vulnerability comes
> from.

Sortry but I do not understand how this patch can be correct. In the best 
case, it will waste three network round trips to fail to negotiate SMB1, which 
is in itself unacceptable, especially now that we have network preparsing.

In the worst case, you will send the user credential with unnecessarily weak 
protection for an eavesdropper to steal.

> > Downgrading is also going to damage performance that already sucks badly
> > enough with SMB inputs.

> This is a complete other subject.

No, it is not another subject. Spare me your fallacies. Both the security and 
the performance regressions stem directly from this patch.

> Note that this is also completely irrelevant on most modern operating system
> shares,

It is completely relevant. To maximise start-up performance with an SMB2-only 
server, you have to try SMB2 first. To maximise both start-up and run-time 
performance with an SMB2+SMB1 server, you have to try SMB2 first as well.

> as this is now really complicated to activate SMB1 shares on
> supported Windows.

So what? This patch precisely harms usage of non-SMB1 shares.

> The patch *is* a compatibility hack, and yes, this is probably wrong, but
> doing another way causes a functional regression. Again, if you have
> another solution or suggestion, please share it.

Fixing a patch is out of scope of a code review.

I have no tolerance for a non-developer showing up just to troll a reviewer, 
especially me.


More information about the vlc-devel mailing list