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@winehq.org Reporter: dwmw2@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...