Parse error on NTLM_CHALLENGE issued by JCIFS

[GoogleCodeExporter]

When used with server-side authentication implemented by jcifs.http.NtlmSsp
(from Java JCIFS 1.2.13 library) on Tomcat, the handler fails with:

  File
"c:\snapshots\topl_pdn\fo_fip_plato\ToplTools\ToplChangeScripts\ntlm\ntlm.py",
line 229, in parse_NTLM_CHALLENGE_MESSAGE
    TargetInfoLen = struct.unpack("<H",msg2[40:42])[0]
  File "C:\Python25\lib\struct.py", line 87, in unpack
    return o.unpack(s)
struct.error: unpack requires a string argument of length 2

This is because the length of NTLMSSP data produced by JCIFS is 32 bytes.
The issue can be resolved by commenting out lines 228-242 in ntlm.py (r8).
These lines seem to be redundant anyway since they don't contribute to
parse_NTLM_CHALLENGE_MESSAGE() return value.

Attached is a packet capture file showing the message produced by JCIFS.

Original issue reported on code.google.com by maciek.m...@gmail.com on 3 Feb 2009 at 1:13

• Merged into: #28

Attachments:

• jcifs.pcap

[GoogleCodeExporter]

The original error message for ntlm.py r8 pointed to line 228 -- the above was
produced after some modification I introduced.

Original comment by maciek.m...@gmail.com on 3 Feb 2009 at 1:18

[GoogleCodeExporter]

I'm having the same problem.  My initial attempt to connect returns a 401 with 
the header:

www-authenticate: NTLM TlRMTVNTUAACAAAAAAAAACgAAAABggAAVU9wgQTnlrgAAAAAAAAAAA==

Parsing the base64 portion, I get this:

0000   4E 54 4C 4D 53 53 50 00 02 00 00 00 00 00 00 00    NTLMSSP.........
0010   28 00 00 00 01 82 00 00 B6 70 AC 57 8C D0 07 44    (........p.W...D
0020   00 00 00 00 00 00 00 00                            ........

That in turn parses into this:

Signature = NTLMSSP
msg_type = 2
TargetNameLen = 0
TargetNameMaxLen = 0
TargetNameOffset = 40
NegotiateFlags = 0x8201
ServerChallenge = B6 70 AC 57 8C D0 07 44

The ntlm module is crashing in its parse_NTLM_CHALLENGE_MESSAGE routine because 
the packet is too short. Starting at offset 0x0020, there is apparently 
supposed to be a 16-byte reserved area followed by three more 32-bit integers, 
instead there's only 8 bytes of hex 00 in the reserved area and the other 
numbers are missing. I'm suspecting that the TargetNameLen being 0 means 
something special.  Can someone help me interpret the data that I'm getting so 
we can get this fixed?

Original comment by samw...@gmail.com on 1 Feb 2013 at 6:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The attached patch fixes the problem.

Original comment by samw...@gmail.com on 5 Feb 2013 at 2:27

Attachments:

• samwyse-2012-02-04.patch

[GoogleCodeExporter]

Original comment by samw...@gmail.com on 12 Feb 2013 at 12:42

• Changed state: Started
• Added labels: Component-Logic, Usability

[GoogleCodeExporter]

Original comment by samw...@gmail.com on 12 Feb 2013 at 12:57

• Changed state: Duplicate