Search squid archive

Re: Problems with helper ntlm_fake_auth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/10/2013 10:54 p.m., Vonlanthen, Elmar wrote:
Hello all

There are some problems with the helper module ntlm_fake_auth. I did the tests with Squid-3.2.13 but 3.3.9 is affected as well.

Hi Volanthen,
  First off thank you for testing this in such detail.

FYI: in future this type of code related post should be sent to squid-dev mailing list. Thank you.

The big problem we have is that none of the current development team are able to test the NTLM helpers properly. So your assistance in that area is very welcome. I am applying the latter two fixes now. The first one is affected by those and the behaviour may change as a result.

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...


Now, if I tweak the header with setting authenticate_ntlm_domain to an empty string and tweaking the target value and payload, it is working (ugly workaround, I know):

diff -aur a/helpers/ntlm_auth/fake/ntlm_fake_auth.cc b/helpers/ntlm_auth/fake/ntlm_fake_auth.cc
--- a/helpers/ntlm_auth/fake/ntlm_fake_auth.cc  2013-09-30 11:48:40.231386531 +0200
+++ b/helpers/ntlm_auth/fake/ntlm_fake_auth.cc  2013-10-01 10:28:07.727699795 +0200
@@ -96,7 +96,7 @@
  #define SEND4(X,Y,Z,W) {debug("sending '" X "' to squid\n",Y,Z,W); printf(X "\n",Y,Z,W);}
  #endif
-const char *authenticate_ntlm_domain = "WORKGROUP";
+const char *authenticate_ntlm_domain = "";
  int strip_domain_enabled = 0;
  int NTLM_packet_debug_enabled = 0;
@@ -209,8 +209,14 @@
              } else {
                  ntlm_make_challenge(&chal, authenticate_ntlm_domain, NULL, nonce, NTLM_NONCE_LEN, NTLM_NEGOTIATE_ASCII);
              }
+            // 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?


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.

Amos




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux