[Bug 37063] New: NTLM EncryptMessage/DecryptMessage failure
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(a)winehq.org Reporter: dwmw2(a)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.
http://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #1 from dwmw2(a)infradead.org <dwmw2(a)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.
http://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #2 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to dwmw2(a)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(a)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.
http://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #3 from dwmw2(a)infradead.org <dwmw2(a)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.
http://bugs.winehq.org/show_bug.cgi?id=37063 dwmw2(a)infradead.org <dwmw2(a)infradead.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #49254|0 |1 is obsolete| | --- Comment #4 from dwmw2(a)infradead.org <dwmw2(a)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(a)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(a)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.
http://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #5 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to dwmw2(a)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(a)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(a)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.
http://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #6 from dwmw2(a)infradead.org <dwmw2(a)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.
https://bugs.winehq.org/show_bug.cgi?id=37063 Austin English <austinenglish(a)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.
https://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #7 from dwmw2(a)infradead.org <dwmw2(a)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&pathrev=67 (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.
https://bugs.winehq.org/show_bug.cgi?id=37063 dwmw2(a)infradead.org <dwmw2(a)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.
https://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #8 from dwmw2(a)infradead.org <dwmw2(a)infradead.org> --- I submitted the patch as requested. Is something supposed to happen now? https://www.winehq.org/pipermail/wine-patches/2014-August/133863.html -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37063 --- Comment #9 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to dwmw2(a)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.
https://bugs.winehq.org/show_bug.cgi?id=37063 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |STAGED CC| |michael(a)fds-team.de, | |sebastian(a)fds-team.de Ever confirmed|0 |1 Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/secur32-ANSI_N | |TLM_Credentials -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37063 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Fixed by SHA1| |5cc400ed60668e1739e82da1cf9 | |0ac8d6c22400b Resolution|--- |FIXED --- Comment #10 from Alistair Leslie-Hughes <leslie_alistair(a)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.
https://bugs.winehq.org/show_bug.cgi?id=37063 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #11 from Alexandre Julliard <julliard(a)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.
https://bugs.winehq.org/show_bug.cgi?id=37063 Michael Stefaniuc <mstefani(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.8.x CC| |mstefani(a)redhat.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37063 Michael Stefaniuc <mstefani(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |--- --- Comment #12 from Michael Stefaniuc <mstefani(a)redhat.com> --- Removing 1.8.x milestone from bugs included in 1.8.4. -- 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.
participants (1)
-
wine-bugs＠winehq.org