Fwd: [PATCH 1/7] cifs: Bypass windows extended security for ntlmv2 negotiate
simo at samba.org
Thu Aug 21 22:17:27 MDT 2014
On Fri, 2014-08-22 at 14:32 +1200, Andrew Bartlett wrote:
> On Wed, 2014-08-20 at 23:51 -0500, Steve French wrote:
> > This is an unusual sounding issue. Any comments on this from the auth experts?
> > Seems better to investigate this more if we end up enforcing a "must
> > be within 5 minutes" threshold instead of this patch. Have we done a
> > dochelp on this before?
> I am certainly nervous about this patch, as I've not ever seen this
> before. The thing that makes me feel particularly odd about this is
> that: In general, NTLMSSP clients don't have the server's time,
This is simply false.
Modern servers send the server timestamp in the TargetInfo Av_Pair
structure in the challenge message [see MS-NLMP 126.96.36.199].
In [MS-NLMP 188.8.131.52.2] it is explicitly mentioned that the client must
use the provided (from the server) timestamp if present or current time
if it is not.
Not only a modern server *should* send a timestamp, but a modern client,
on seeing that a timestamp is available should provide a MIC in the
Authentication message [MS-NLMP 184.108.40.206.2].
Unfortunately samba at the moment has a very limited and incomplete
implementation of the NTLM protocol and doesn't do much with targetinfo
except mocking it up a little.
An implementation that is very close to implementing all of the MS-NLMP
specification is here:
or here: https://fedorahosted.org/gss-ntlmssp/
and I hope to make samba use it eventually, when we have a more decent
set of interfaces to connect to DCs (the current winbind interfacing is
suboptimal but fixable).
> and certainly don't have the domain controller's time.
This is true but not a problem today were servers are supposed to have
the time in sync with the KDC/Domain Controller anyway.
> (That CIFS provides
> this does not mean we should use it, NTLMSSP is a general protocol and
> adding CIFS-specific hacks indicates we are understanding it wrong, in
> my experience).
> BTW, the domain controller is the only element here that could check the
> embedded time, but I'll grant that typically servers are better in sync
> with each other than this embedded device might be.
> The 5 mins stuff probably refers to Kerberos, which does have such a
> time limit. I've never seen NTLMSSP fail against windows due to clock
That's becasue a client is supposed to use the time provided by the
server, so no clockskew is really possible,
> I would like to see much more investigation here before this is done,
> because if you just trust the server's time and if you need to, to pass
> a security check, you override that check. We need to understand why it
> is in place.
Sorry but this makes no sense, if you can bypass a "security mechanism"
in the client, then there is *no* security mechanism.
The reason why a timestamp is provided by the server is (most probably)
to mitigate replay attacks when the client uses a MIC (as it should)
when the timestamp is provided.
More information about the samba-technical