https://bugs.winehq.org/show_bug.cgi?id=50721
Bug ID: 50721 Summary: IDA Pro 7.5: Lumina can't contact server, complains about Schannel security attributes Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 Assignee: wine-bugs@winehq.org Reporter: thotypous@gmail.com Distribution: ---
Using Wine Staging, IDA Pro fails to contact the Lumina server when trying to do any operation that depends on it (e.g. Lumina menu -> Pull All Metadata). The IDA's output window shows "lumina: Schannel does not support the requested security attributes"
By tracing secur32, it turns out that InitializeSecurityContextA is being called with fContextReq flags ISC_REQ_EXTENDED_ERROR and ISC_REQ_MANUAL_CRED_VALIDATION, which are not handled by Wine:
00f4:trace:secur32:InitializeSecurityContextA 0x3436e40 0x3436e50 (null) 0x0008c110 0 0 0x529b58 0 (nil) 0x529af8 0x3436e9c (nil)
Now regarding each flag:
1. ISC_REQ_EXTENDED_ERROR: according to MSDN, this flag means "When errors occur, the remote party will be notified."
However, modern TLS does not have any mechanism to notify the remote party about errors. Thus it seems unlikely that this flag causes any difference in behavior, at least when the remote party is not running Microsoft's TLS implementation.
When researching about the flag, I found https://mskb.pkisolutions.com/kb/975858, which states Windows 7 used to ignore this flag, but since it caused issues with some applications, they changed schannel to return ISC_RET_EXTENDED_ERROR (via pfContextAttr) when the flag is set. The KB does not describe any other change deployed by the upgrade. This fact further supports the hypothesis that the flag does not change the behavior of the protocol.
In short, up-to-date Windows 7 seems to just return ISC_RET_EXTENDED_ERROR when ISC_REQ_EXTENDED_ERROR is set, but otherwise ignores it.
2. ISC_REQ_MANUAL_CRED_VALIDATION: according to MSDN, this flag means "By default, Schannel validates the server certificate by calling the WinVerifyTrust function; however, if you have disabled this feature using the ISC_REQ_MANUAL_CRED_VALIDATION flag, you must validate the certificate provided by the server that is attempting to establish its identity."
However, Wine currently does not carry automatic server certificate validation at all. The OSX implementation always calls "SSLSetEnableCertVerify(s->context, FALSE)" to disable it explicitly. The GnuTLS implementation never calls "gnutls_session_set_verify_cert", which would be required to enable server certificate validation.
Strictly speaking, the current implementation of Schannel in Wine is insecure, but fixing it would require more extensive changes to the code and could cause regression bugs with other applications. Thus, I argue it should be dealt with by another bug entry and fixed by another patch.
Therefore, the attached patch restricts itself to return ISC_RET_MANUAL_CRED_VALIDATION when ISC_REQ_MANUAL_CRED_VALIDATION is set, and to better document the current situation in the code.
https://bugs.winehq.org/show_bug.cgi?id=50721
--- Comment #1 from Hans Leidekker hans@meelstraat.net --- (In reply to Paulo Matias from comment #0)
- ISC_REQ_MANUAL_CRED_VALIDATION: according to MSDN, this flag means "By
default, Schannel validates the server certificate by calling the WinVerifyTrust function; however, if you have disabled this feature using the ISC_REQ_MANUAL_CRED_VALIDATION flag, you must validate the certificate provided by the server that is attempting to establish its identity."
However, Wine currently does not carry automatic server certificate validation at all. The OSX implementation always calls "SSLSetEnableCertVerify(s->context, FALSE)" to disable it explicitly. The GnuTLS implementation never calls "gnutls_session_set_verify_cert", which would be required to enable server certificate validation.
This is because we would need to use Win32 APIs to verify the certificate. That way we have access to the right CA certificate store and apply the right policy.
Strictly speaking, the current implementation of Schannel in Wine is insecure, but fixing it would require more extensive changes to the code and could cause regression bugs with other applications. Thus, I argue it should be dealt with by another bug entry and fixed by another patch.
Therefore, the attached patch restricts itself to return ISC_RET_MANUAL_CRED_VALIDATION when ISC_REQ_MANUAL_CRED_VALIDATION is set, and to better document the current situation in the code.
That's fine. You may also want to add test case.
https://bugs.winehq.org/show_bug.cgi?id=50721
--- Comment #2 from Paulo Matias thotypous@gmail.com --- Created attachment 69470 --> https://bugs.winehq.org/attachment.cgi?id=69470 Patch for fixing the bug
https://bugs.winehq.org/show_bug.cgi?id=50721
--- Comment #3 from Paulo Matias thotypous@gmail.com --- (In reply to Hans Leidekker from comment #1)
This is because we would need to use Win32 APIs to verify the certificate. That way we have access to the right CA certificate store and apply the right policy.
Thank you for the explanation. So a proper fix would be even more complicated than I was anticipating.
That's fine. You may also want to add test case.
OK. I have just attached the patch to fix the bug itself. I will work on a test case and attach it as a separate patch.
https://bugs.winehq.org/show_bug.cgi?id=50721
Paulo Matias thotypous@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Paulo Matias thotypous@gmail.com --- Fixed by ed06d64bf41cc3eb6258a3576e845a544855b0be
https://bugs.winehq.org/show_bug.cgi?id=50721
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.5.