Sorry for not replying sooner.
On Tue, 2003-07-22 at 04:04, Guy Harris wrote:
> http://www.opengroup.org/onlinepubs/009629399/chap13.htm
>
> See the "Common Authentication Verifier Encodings" section, which says:
>
> The auth_pad field is required to restore 0 mod 4 alignment following
> the stub data, if any. It consists of 0, 1, 2 or 3 null bytes.
Ah. Ok. My bad for not RTFM.
> Perhaps Microsoft "embraced and extended" that field to specify padding
> to make the stub data a multiple of 16 bytes for NTLMSSP (I think I
> mentioned that possibility in mail on this topic a while ago), but the
> DCE RPC 1.1 spec, at least, seems to indicate that it's there to align
> the fields of an "auth_verifier_co_t" on a 4-byte boundary.
I don't see any incentive from a design standpoint, but who knows....
My only thought was if they wanted to work with block ciphers that
operate on 128 bits at a time. I know you mentioned this previously,
and I had forgotten.
> > (which is zeros).
>
> Not always - in a capture that I think you sent out, named
> "new_nt4w_to_nt4s_passchange_abcd_to_efgh", in frame 26 the 12 bytes of
> padding aren't all zero.
Argh, you're right. I can't explain this. Perhaps in some requests
they pad out the memory with zeros, in other requests they just send
whatever kernel memory is in that location? (which of course would
represent an information leak). Or perhaps it means something and the
decryption is failing.
> I might, however, be inclined to show that frame with the NTLMSSP
> verifier, followed by encrypted stub data, decrypted stub data, and
> padding, and then show after that the SAMR dissection (as I see the
> encryption as part of DCE RPC, not of SAMR, and would expect the
> protocol-atop-DCERPC part of the tree for an encrypted packet to look
> the same as it would if that data hadn't been encrypted).
I agree that the padding should not be shown as part of the SAMR tree as
this is clearly a function of DCE/RPC. However, it always bothered me
that we dissect the verifier before the encrypted stub, since it always
comes after the stub in the packet. I know we do this because of some
hacks to figure out the size of the block to dissect, but it's still
seems counterintuitive.
Now that I'm rereading your remark, I'm wondering if the main idea
you're trying to get across is that you would like to move the SAMR
dissection to the end, completely after the DCE/RPC. If that's the
case, I have no specific objection.
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc.
