[Bug 59275] New: Multiple applications require system DLLs to pass WinVerifyTrust/CryptCATAdminEnumCatalogFromHash
http://bugs.winehq.org/show_bug.cgi?id=59275 Bug ID: 59275 Summary: Multiple applications require system DLLs to pass WinVerifyTrust/CryptCATAdminEnumCatalogFromHash Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wintrust Assignee: wine-bugs@list.winehq.org Reporter: mkrsym1@gmail.com Distribution: --- Multiple applications expect system DLLs to be signed with a trusted certificate, or for their hashes to be present in a CAT file signed with a trusted certificate. The two specific APIs for this are WinVerifyTrust and CryptCATAdminEnumCatalogFromHash. Non-exhaustive list of things I know in particular: - Games using TPShell protector > Dec 2025 (Duet Night Abyss, ...). Check triggers if the module is attempted to be loaded from KiUserApcDispatcher/KiUserCallbackDispatcher. This results in winex11.drv, uxtheme.dll, ... being rejected, as they don't have a trusted signature. Verification is by both VerifyTrust and CatalogFromHash. Testing is hindered by kernel driver. - Honkai: Star Rail wants d3d9.dll, d3d11.dll, dxgi.dll to be present in CatalogFromHash, terminates on load otherwise. Previous mention of similar issue: https://bugs.winehq.org/show_bug.cgi?id=54836 . Mentions that "it may deserve some discussion", which I assume never took place. A potential solution I see is to allow (optionally?) specifying a certificate and a signing key at ./configure time, which would then be used to sign the DLLs, afterwards a catalog will be generated and signed by it too. The certificate would then be installed via wine.inf. This however comes at a cost of technically making builds non-reproducible, unless the signing key is public? Alternatively, maybe it could be possible to generate a new authority on every ./configure? Another potential "solution" would be to make both APIs pretend that builtin DLLs are signed, which I would imagine comes with it's own set of issues. -- 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=59275 mkrsym1@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation CC| |mkrsym1@gmail.com, | |z.figura12@gmail.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.
http://bugs.winehq.org/show_bug.cgi?id=59275 --- Comment #1 from Hans Leidekker <hans@meelstraat.net> --- (In reply to mkrsym1 from comment #0)
A potential solution I see is to allow (optionally?) specifying a certificate and a signing key at ./configure time, which would then be used to sign the DLLs, afterwards a catalog will be generated and signed by it too. The certificate would then be installed via wine.inf. This however comes at a cost of technically making builds non-reproducible, unless the signing key is public? Alternatively, maybe it could be possible to generate a new authority on every ./configure?
I think it's reasonable for Wine's build system to support signing DLLs but it can be done separately as well. You would need to supply a valid certificate for WinVerifyTrust to succeed of course. For reproducible builds you could do what CryptCATAdminCalcHashFromFileHandle() does: it skips the parts of a PE image that change when you sign it.
Another potential "solution" would be to make both APIs pretend that builtin DLLs are signed, which I would imagine comes with it's own set of issues.
Verifying the signature is a way for the app to check that it's using unmodified DLLs and we should support that. Apps could go one step further and check that the publisher is MS. Then your options are to accept that the app doesn't want to run on Wine or you could spoof a valid signature. I don't think we want to make that decision for the user. -- 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=59275 --- Comment #2 from mkrsym1@gmail.com ---
but it can be done separately as well
I assume the idea here is making a separate script (similar idea to winetricks) that could be used to sign the Wine DLLs in a build/prefix with a supplied certificate. That does sound reasonable.
Apps could go one step further and check that the publisher is MS
Many (most?) applications do not go "one step further" and just want the DLLs to be signed by anything, as long as the system trusts it. A specific check for signature being MS is a completely different question out of the scope of this one. -- 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=59275 --- Comment #3 from Hans Leidekker <hans@meelstraat.net> --- (In reply to mkrsym1 from comment #2)
but it can be done separately as well
I assume the idea here is making a separate script (similar idea to winetricks) that could be used to sign the Wine DLLs in a build/prefix with a supplied certificate. That does sound reasonable.
I imagine packagers would do it after 'make install'.
Apps could go one step further and check that the publisher is MS
Many (most?) applications do not go "one step further" and just want the DLLs to be signed by anything, as long as the system trusts it. A specific check for signature being MS is a completely different question out of the scope of this one.
Sure, what I'm saying is that you don't need to spoof anything if the app is only interested in a valid signature. -- 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=59275 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.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.
http://bugs.winehq.org/show_bug.cgi?id=59275 --- Comment #4 from mkrsym1@gmail.com --- After thinking about it for a while, I came up with the following idea: have a registry switch (e.g. HKCU\Software\Wine->TrustBuiltinDlls, could be enabled by default?) to make WinVerifyTrust succeed for DLLs with "Wine builtin DLL" even if they don't have a signature. This would allow upstream builds to run problematic applications without extra packager effort, and if the packagers want to actually sign the DLLs, they can just do that and ship with TrustBuiltinDlls disabled. I understand the desire to have everything work exactly in-line with real Windows, but I believe that this particular change could be very useful, as the proper fix of actually signing everything is quite cumbersome for the packagers, so I expect that most would not bother. --- New entry on the problematic list, "Arknights: Endfield" rejects uxtheme.dll and msimg32.dll by WinVerifyTrust. winex11.drv is verified but not rejected due to a bug in the protector. -- 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=59275 reelix@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |reelix@gmail.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.
participants (1)
-
WineHQ Bugzilla