AW: [squid-users] Problems with helper ntlm_fake_auth

Hello Amos

> -----Ursprüngliche Nachricht-----
> Von: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Gesendet: Dienstag, 8. Oktober 2013 03:35
> An: squid-users_at_squid-cache.org
> Betreff: Re: [squid-users] Problems with helper ntlm_fake_auth
>
> FYI: in future this type of code related post should be sent to squid-dev
> mailing list. Thank you.

Ok, I will do that next time.

> > The first problem is that the NTLM response header of type "TT" will be
> generated wrong.
> >
> > This one has been generated with the new helper ntlm_fake_auth:
> > ntlm_fake_auth.cc(219): pid=29811 :sending 'TT' to squid with data:
> > [0000] 4E 54 4C 4D 53 53 50 00 02 00 00 00 09 00 09 00 NTLMSSP. ........
> > [0010] 28 00 00 00 07 82 08 A2 CE 7D 62 FA 44 55 80 E0 ........ ..b.DU..
> > [0020] 00 00 00 00 00 00 3A 00 57 4F 52 4B 47 52 4F 55 ........ WORKGROU
> > [0030] 50 P
> >
> > And this one with the old helper fakeauth_auth (which is working):
> > ntlm-auth[31700](fakeauth_auth.c:421): sending 'TT' to squid with data:
> > [0000] 4E 54 4C 4D 53 53 50 00 02 00 00 00 0A 00 0A 00 NTLMSSP. ........
> > [0010] 30 00 00 00 07 82 08 A2 7B E5 5C 0B 49 DB 6D 36 0....... ....I.m6
> > [0020] 00 00 00 00 00 00 00 00 00 00 00 00 3A 00 00 00 ........ ........
> > [0030] 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....
> >
> > It seems that the total length of the header has a wrong size and the char
> ":" (0x3a) will be placed in the field "reserved". The client doesn't accept the
> packet with the new response header and is sending a RST.
>
> Total length being the wrong size can be expected after the 3rd problem you
> mention below. The entire structure is dependent on field sizes being
> calculated and encoded correctly. Otherwise random extra space or barbage
> ends up in the output. Those 00 octets at the end look suspiciously like such.
> Can you please test this problem again and re-do the analysis after the size
> and case patches are applied. A re-analysis on fixed field contents may help
> with that TODO answer...

Unfortunately it doesn't work with only the patches 2 and 3:

2013/10/08 09:06:20.215 kid1| auth_ntlm.cc(248) fixHeader: Sending type:40 header: 'NTLM TlRMTVNTUAACAAAACQAJACgAAAAHggiizn1i+kRVgOAAAAAAAAA6AFdPUktHUk9VUA=='
ntlm_fake_auth.cc(219): pid=5679 :sending 'TT' to squid with data:
[0000] 4E 54 4C 4D 53 53 50 00 02 00 00 00 09 00 09 00 NTLMSSP. ........
[0010] 28 00 00 00 07 82 08 A2 CE 7D 62 FA 44 55 80 E0 ........ ..b.DU..
[0020] 00 00 00 00 00 00 3A 00 57 4F 52 4B 47 52 4F 55 ........ WORKGROU
[0030] 50 P

Wireshark shows this:
NTLM Secure Service Provider
  NTLMSSP identifier: NTLMSSP
  NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002)
  Target Name: ???? <<< Why "????"
    Length: 9
    Maxlen: 9
    Offset: 40
  Flags: 0xa2088207
  NTLM Server Challenge: 074657c2b2de2963
  Reserved: 0000000000003a00 <<< 3a is still in the "Reserved" field
                                <<< address list is missing>

Compare it with fakeauth_auth:
NTLM Secure Service Provider
  NTLMSSP identifier: NTLMSSP
  NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002)
  Target Name:
    Length: 10
    Maxlen: 10
    Offset: 48
  Flags: 0xa2088207
  NTLM Server Challenge: 074657c2b2de2963
  Reserved: 0000000000000000
  Address List: Empty

> > + // doesn't work with this:
> > // TODO: find out what this context means, and why only the fake
> auth helper contains it.
> > - chal.context_high = htole32(0x003a<<16);
> > + //chal.context_high = htole32(0x003a<<16);
> > + // twead payload, offset and length to get it working:
> > + chal.payload[4] = 0x3a;
> > + chal.target.offset = 48;
> > + chal.target.len = 10;
> > + chal.target.maxlen = 18;
> >
> > len = sizeof(chal) - sizeof(chal.payload) +
> le16toh(chal.target.maxlen);
> > data = (char *) base64_encode_bin((char *) &chal, len);
> >
> > In the code there is a comment "TODO: find out what this context
> > means...". I think there is really some work to do. ;-)
>
> Yes there is. The other helpers are working perfectly fine without this
> context value being set. Which is why it was elided from these versions.
> Before this gets changed yet again, do you have any explanation for what
> those seemingly arbitrary random values mean?

You mean "0x003a<<16"? I don't now, but if these value is set, wireshark will show further field "Address List" set to "Empty". See above.

If I compare the old fakeauth_auth module with the new ntlm_fake_auth I see that in squid-3.1 the ntlm_challenge struct had a variable "unknown" with a length of 16 bytes, this has been replaced in squid-3.2 with two fields of 4 bytes (totally 8 bytes).
Aren't there 8 bytes missing?

Squid 3.1:
/* Challenge request sent by server. */
struct ntlm_challenge {
    ntlmhdr hdr; /* NTLM header */
    strhdr target; /* Authentication target (domain/server ...) */
    int32_t flags; /* Request flags */
    u_char challenge[8]; /* Challenge string */
    int16_t unknown[8]; /* Some sort of context data */
    char pad[256]; /* String data */
};

Squid 3.2:
    /** Challenge request sent by server. */
    typedef struct _ntlm_challenge {
        ntlmhdr hdr; /**< "NTLMSSP" , LSWAP(0x2) */
        strhdr target; /**< Authentication target (domain/server ...) */
        uint32_t flags; /**< Request flags */
        u_char challenge[NTLM_NONCE_LEN]; /**< Challenge string */
        uint32_t context_low; /**< LS part of the server context handle */
        uint32_t context_high; /**< MS part of the server context handle */
        char payload[256]; /**< String data */
    } ntlm_challenge;

> > Another problem is the presentation of domain and username. First the
> domain was previously shown in uppercase. This could make problems with
> case sensitive acls:
> > And the last problem is a wrong specification of the string length for
> domain and username. The last char of each string is missing. The problem is
> that the string length will be initialized with -1:
>
> Okay. Slightly polished patches applied for these.

Thank you very much!

Best regards
Elmar