[Bug 37063] New: NTLM EncryptMessage/DecryptMessage failure

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=37063

            Bug ID: 37063
           Summary: NTLM EncryptMessage/DecryptMessage failure
           Product: Wine
           Version: 1.7.22
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: secur32
          Assignee: wine-bugs at winehq.org
          Reporter: dwmw2 at infradead.org

Created attachment 49252
  --> http://bugs.winehq.org/attachment.cgi?id=49252
Test case

Attached is a test case based on GSSAPI authentication to a SOCKS proxy
(RFC1961). An alternative summary for this bug could be "OpenConnect VPN server
cannot authenticate to SOCKS proxy", since that's where this test code is
derived from.

The protocol is fairly simple — it's a GSSAPI exxchange followed by a single
byte 0x00 being sent in each direction under "wrapping" by gss_wrap() or
EncryptMessage(). We are only supposed to be using integrity protection
(signing), not encryption.

Testing has been done against a Dante SOCKS server using gss-ntlmssp.

Windows testing has been done under Windows 7 64-bit, set to use NTLMv1 & LMv1
(I don't seem to have permissions to change that for testing NTLMv2).

There are various issues with wine's emulation which make it fail once
gss-ntlmssp has been made to work correctly with Windows. I'm not sure if it's
best to file separate bugs for each or whether to track them together.

Firstly, wine seems to mishandle the Password field in SEC_WINNT_AUTH_IDENTITY
unless it's in Unicode mode; using SEC_WINNT_AUTH_IDENTITY_ANSI doesn't work
because the password that gets passed to ntlm_auth is mangled.

Secondly, it looks like the Domain field is ignored too and we just pass
'--domain=' to ntlm_auth.

(There's a separate bug filed at
https://bugzilla.samba.org/show_bug.cgi?id=10691 for ntlm_auth not giving us
the session key back when it's using default credentials, and the *flags* are
wrong in that case too because they are missing the NTLMSSP_NEGOTIATE_SIGN/SEAL
bits, but that's probably Samba bug).

Third... it looks like Windows will always encrypt messages, even when
ISC_REQ_CONFIDENTIALITY is *not* in the InitializeSecurityContext flags and
SECQOP_WRAP_NO_ENCRYPT is set. But wine doesn't, so the first 'encrypted'
message fails in gss_unwrap() on the server side.

If we do use ISC_REQ_CONFIDENTIALITY (or bypass the NTLM2&&SEAL check in
ntlm_EncryptMessage() and make it always take that path, sending a wrapped
message works but then...

Fourth, we fail to *unwrap* the returned message. It's looking for a
SECBUFFER_TOKEN buffer in the array, but as far as I can tell, NTLM
DecryptMessage() takes SECBUFFER_STREAM and a SECBUFFER_DATA. The documentation
on this is sparse, but this code does work under Windows...

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.