http://bugs.winehq.org/show_bug.cgi?id=60231 Bug ID: 60231 Summary: WinVerifyTrust/CryptMsgControl(CMSG_CTRL_VERIFY_SIGNAT URE) rejects valid Authenticode signatures whose authenticatedAttributes don't survive re-encoding round-trip Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs@list.winehq.org Reporter: digitallyremastered128@gmail.com Target Milestone: --- Distribution: --- CSignedMsgData_UpdateAuthenticatedAttributes() in dlls/crypt32/msg.c re-encodes a SignerInfo's authenticatedAttributes from the decoded CRYPT_ATTRIBUTES representation (via CryptEncodeObjectEx(PKCS_ATTRIBUTES, ...)) before hashing it, even when *verifying* a signature (as opposed to creating one). Per RFC 2315/PKCS#7, what actually gets hashed for signature verification purposes is the DER encoding of authenticatedAttributes exactly as the signer originally produced it (re-tagged from [0] IMPLICIT to a universal SET, content octets otherwise untouched) - not an independent re-encoding produced by decoding into this library's own internal structure and re-serializing it. Re-encoding an arbitrary already-decoded ASN.1 structure is not guaranteed to byte-for-byte reproduce what the original signer encoded, particularly for opaque/vendor-specific attributes this generic encoder has no precise custom handling for (e.g. Microsoft's SPC_SP_OPUS_INFO attribute, used in every Authenticode signature). When the round-trip doesn't match, the hash computed here diverges from the one actually covered by the RSA signature, and verification is incorrectly reported as failed - even though the RSA signature itself decrypts correctly and the file's actual content digest matches what's embedded in the signature. Reproduction: Any Authenticode-signed PE file whose signer's authenticatedAttributes don't happen to round-trip identically through Wine's re-encoder will fail verification. A concrete, currently-reproducible example: - Download FL Studio 26.1.4.5589's installer or the FLEngine_x64.dll it installs (Image-Line, https://www.image-line.com - signed under a current "Image Line NV" certificate). - Under Wine, either: (a) run FL64.exe - it shows "The validity of the program could not be verified. Please reinstall it and try returns TRUST_E_CERT_SIGNATURE (0x80096004). - The same application's earlier build (e.g. 24.2.2.4597 or 25.2.5.5319, signed under Image-Line's previous certificate) verifies successfully with the exact same Wine build - confirming this is about the specific file's signature encoding, not Wine's general Authenticode support, RSA/crypto math, or the certificate's key size. Root-cause investigation: Traced with live debugging (breakpoints on RSAENH_CPVerifySignature and hash_file_data, register/memory inspection) confirmed, in order: 1. The RSA public-key decrypt operation (via the vendored SymCrypt library) succeeds and produces valid PKCS#1 v1.5-padded output - RSA math itself is not the problem. 2. The PE-content hash (SOFTPUB_HashPEFile) is computed with fully correct boundaries and matches the actual embedded SpcIndirectDataContent.digest field exactly (verified independently via direct ASN.1 inspection) - the file-content hashing is not the problem either. 3. The mismatch is specifically between CSignedMsgData_UpdateAuthenticatedAttributes's re-encoded-attributes hash and the RSA-decrypted value, which is the hash of the original authenticatedAttributes bytes. A patch is ready (preserves the original encoded SignedData bytes at decode time and hashes the original authenticatedAttributes bytes directly instead of re-encoding, falling back to the previous behavior if anything about the original bytes doesn't parse as expected). Verified fixed against the file above with no regression on the previously-working build, Wine's own crypt32 msg.c test suite (1026 tests, 0 failures), and additionally checked against Google Chrome's and Mozilla Firefox's own signed executables (both continue to verify correctly). Will link the merge request here once opened. -- 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.