[Bug 37063] New: NTLM EncryptMessage/DecryptMessage failure

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

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

Show replies by date

wine-bugs＠winehq.org

7 Aug 7 Aug

11:51 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

--- Comment #1 from dwmw2@infradead.org dwmw2@infradead.org --- Created attachment 49254 --> http://bugs.winehq.org/attachment.cgi?id=49254 Cope with SEC_WINNT_AUTH_IDENTITY_ANSI

This fixes the easy part.. the domain seems to be present and correct now too.

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

wine-bugs＠winehq.org

8 Aug 8 Aug

9:34 a.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

--- Comment #2 from Hans Leidekker hans@meelstraat.net --- (In reply to dwmw2@infradead.org from comment #1)

Created attachment 49254 [details] Cope with SEC_WINNT_AUTH_IDENTITY_ANSI

This fixes the easy part.. the domain seems to be present and correct now too.

Looks good. Please submit it to wine-patches@winehq.org.

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

wine-bugs＠winehq.org

9:35 a.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

--- Comment #3 from dwmw2@infradead.org dwmw2@infradead.org --- I've made the DecryptMessage part work in wine by passing a SECBUFFER_TOKEN of 16 bytes and the rest in a SECBUFFER_DATA. And that works for NTLM under Windows too.

However, even if I generalise that to use sizes.cbMaxSignature instead of a hard-coded 16, it doesn't work for Kerberos. I receive a 29-byte encrypted message, pass the first 28 of it in the SECBUFFER_TOKEN and the next in the SECBUFFER_DATA, and Windows still doesn't like it; I get SEC_E_MESSAGE_ALTERED.

I can't find where SECBUFFER_STREAM is even documented — it isn't mentioned at http://msdn.microsoft.com/en-us/library/windows/desktop/aa379814%28v=vs.85%2...

Neither can I recall why I'm using it; I have a vague recollection of finding a mailing list archive somewhere, where the lack of good documentation on this was lamented and someone authoritative said this was the way to do it... which does appear to be true, under Windows.

At http://msdn.microsoft.com/en-us/library/windows/desktop/aa375205%28v=vs.85%2... another layout (SECBUFFER_DATA, SECBUFFER_EMPTY*3) is used... which doesn't actually work under Wine *or* 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.

wine-bugs＠winehq.org

10:16 a.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

dwmw2@infradead.org dwmw2@infradead.org changed:

--- Comment #4 from dwmw2@infradead.org dwmw2@infradead.org --- Created attachment 49257 --> http://bugs.winehq.org/attachment.cgi?id=49257 Convert from CP_ACP to UTF16 and then to CP_UNIXCP for SEC_WINNT_AUTH_IDENTITY_ANSI

(In reply to Hans Leidekker from comment #2)

(In reply to dwmw2@infradead.org from comment #1)

...
Created attachment 49254 [details] Cope with SEC_WINNT_AUTH_IDENTITY_ANSI

This fixes the easy part.. the domain seems to be present and correct now too.

Looks good. Please submit it to wine-patches@winehq.org.

On further reflection... I realise my patch assumes that CP_ACP == CP_UNIXCP. That's not a valid assumption, is it? This being the 21st century, CP_UNIXCP is going to be UTF-8 fairly much everywhere... and the win32 side isn't likely to be using UTF-8 as the ANSI code page because support for that is so broken under Windows.

So perhaps I need to convert the ANSI strings from CP_ACP to 'Unicode' and then pass them into the (unmolested) ntlm_Get*Arg() functions to be converted to CP_UNIXCP as before? Like this...

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

wine-bugs＠winehq.org

10:36 a.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

--- Comment #5 from Hans Leidekker hans@meelstraat.net --- (In reply to dwmw2@infradead.org from comment #4)

Created attachment 49257 [details] Convert from CP_ACP to UTF16 and then to CP_UNIXCP for SEC_WINNT_AUTH_IDENTITY_ANSI

(In reply to Hans Leidekker from comment #2)

...
(In reply to dwmw2@infradead.org from comment #1)

...
Created attachment 49254 [details] Cope with SEC_WINNT_AUTH_IDENTITY_ANSI

This fixes the easy part.. the domain seems to be present and correct now too.

Looks good. Please submit it to wine-patches@winehq.org.

On further reflection... I realise my patch assumes that CP_ACP == CP_UNIXCP. That's not a valid assumption, is it? This being the 21st century, CP_UNIXCP is going to be UTF-8 fairly much everywhere... and the win32 side isn't likely to be using UTF-8 as the ANSI code page because support for that is so broken under Windows. So perhaps I need to convert the ANSI strings from CP_ACP to 'Unicode' and then pass them into the (unmolested) ntlm_Get*Arg() functions to be converted to CP_UNIXCP as before? Like this...

Yes, that's better. You should use WCHAR instead of wchar_t. Also note that HeapFree doesn't need the NULL pointer guard.

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

wine-bugs＠winehq.org

12:23 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

--- Comment #6 from dwmw2@infradead.org dwmw2@infradead.org --- (In reply to Hans Leidekker from comment #5)

Yes, that's better. You should use WCHAR instead of wchar_t. Also note that HeapFree doesn't need the NULL pointer guard.

Thanks. I've fixed those, and the fact that I was only freeing the converted strings if the password was set, and sent the patch.

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

wine-bugs＠winehq.org

4:35 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

Austin English austinenglish@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, patch, testcase

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

wine-bugs＠winehq.org

11:27 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

--- Comment #7 from dwmw2@infradead.org dwmw2@infradead.org --- Regarding the buffer layout for DecryptMessage, these are quite enlightening:

http://rc.quest.com/viewvc/authtest/trunk/sspi/wrap.c?r1=57&r2=67&pa... (which links to http://msdn.microsoft.com/en-us/magazine/cc301890.aspx )

"When you receive a GSSAPI encrypted or signed message, you'll describe it with a buffer of type SECBUFFER_STREAM, as shown in Figure 3, and provide that buffer along with a second buffer of type SECBUFFER_DATA that will receive the decrypted message."

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

wine-bugs＠winehq.org

19 Mar 19 Mar

12:33 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

dwmw2@infradead.org dwmw2@infradead.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.22 |1.7.38

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

wine-bugs＠winehq.org

26 Mar 26 Mar

4:27 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

https://www.winehq.org/pipermail/wine-patches/2014-August/133863.html

--- Comment #8 from dwmw2@infradead.org dwmw2@infradead.org --- I submitted the patch as requested. Is something supposed to happen now?

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

wine-bugs＠winehq.org

27 Mar 27 Mar

8:28 a.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

--- Comment #9 from Hans Leidekker hans@meelstraat.net --- (In reply to dwmw2@infradead.org from comment #8)

I submitted the patch as requested. Is something supposed to happen now?

https://www.winehq.org/pipermail/wine-patches/2014-August/133863.html

You should check the HeapAlloc calls for failure (I know that didn't happen before your patch). Otherwise it looks good, please resubmit.

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

wine-bugs＠winehq.org

29 Sep 29 Sep

12:01 a.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

Michael Müller michael@fds-team.de changed:

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

wine-bugs＠winehq.org

27 May 27 May

9:07 a.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:

--- Comment #10 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Fixed http://source.winehq.org/git/wine.git/?a=commit;h=5cc400ed60668e1739e82da1cf...

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

wine-bugs＠winehq.org

2:44 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

Alexandre Julliard julliard@winehq.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED

--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.11.

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

wine-bugs＠winehq.org

13 Jul 13 Jul

9:18 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure

Michael Stefaniuc mstefani@redhat.com changed:

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

wine-bugs＠winehq.org

22 Aug 22 Aug

3:11 p.m.

New subject: [Bug 37063] NTLM EncryptMessage/DecryptMessage failure