[Patch] Always start with the NTLMSSP_NEGOTIATE_ALWAYS_SIGN flag enabled

[Kai Blin]

On Wednesday 22 November 2006 12:03, Volker Lendecke wrote:

Hey folks,

sorry for quoting alot of this, but I'm CCing Rob Shearman on this, as he 
knows alot more about RPC than I do, and want to bring him up to speed.

> On Wed, Nov 22, 2006 at 10:56:17AM +0100, Kai Blin wrote:
> > > For the stupid Volker, can you explain a bit more what you
> > > mean with "dummy signing RPC uses"? What is this exactly?
> >
> > If SSPI is not instructed to enable message integrity and
> > confidentiality, NTLMSSP_NEGOTIATE_SIGN and NTLMSSP_NEGOTIATE_SEAL are
> > not negotiated.
> >
> > While a sane person would expect the calls to MakeSignature and
> > VerifySignature as well as EncryptMessage and DecryptMessage to fail,
> > SSPI will happily run them and succeed anyway. In this case, the
> > signature will be set to 0x01000000000000000000000000000000. According to
> > [1], this will only be done if NTLMSSP_NEGOTIATE_ALWAYS_SIGN is
> > negotiated, which always happens on all the boxes I checked on. RPC seems
> > to always sign packets sent. If no real signing is requested from RPC, it
> > uses the dummy signing.
[...]
> > [1] http://davenport.sourceforge.net/ntlm.html#appendixC6
>
> Not having looked at our DCE/RPC code. Do we do this dummy
> signing? If yes, then this would be a +1 from me.

I have yet to find what exactly is happening in Samba 3. To be honest, that 
code is a mess. It seems like it's silently ignoring any signatures on th 
connection level authentication, which is where Windows uses the dummy 
signature. (see rpc_server/svr_pipe.c, line 1987ff.) I couldn't wrap my head 
around how the actual PDU is constructed in the end.

However, Andrew Bartlett told me to look at Samba 4 code to figure out how 
DCERPC worked, and I found the code dealing with the dummy signature there.
I hope somebody who knows the samba3 code better than I do can find the 
appropriate part there.

>
> Can you point me at the Samba3 code line that does it?

In Samba4, the code doing this is in rpc_server/dcesrv_auth.c, line 367. For 
the connection level authentication, it calls the 
dcesrv_check_connect_verifier() function ( you can find that in the same 
file, lines 286 ff. It checks if the first byte is 1. Right above that, 
there's the dcesrv_connect_verifier() function, which creates a four byte 
number, 0x01 00 00 00, and then adds 12 bytes of 0. This happens to be the 
NTLMSSP dummy signature. Rather than being a seperate case for a signature, 
this actually is a special case of the NTLM SSP signature.

If integrity is requested for RPC, the NTLMSSP verifier (that's how 
Wireshark's DCERPC dissector calls it) is the exact NTLMSSP signature.

Eric Glass calls the NTLMSSP verifier version "NTLMSSP sign version"[2], which 
is what the samba ntlmssp code in libsmb/ntlmssp_sign.c calls it. 

So, anything else you want to see? Rob provided me with some wireshark traces 
that show the behaviour I mentionend. If you like, I can forward them to you.

Cheers,
Kai

[2] http://davenport.sourceforge.net/ntlm.html#ntlm1Signing

-- 
Kai Blin, <kai Dot blin At gmail Dot com>
WorldForge developer    http://www.worldforge.org/
Wine developer          http://wiki.winehq.org/KaiBlin/
--
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20061122/6067fbf6/attachment.bin