[Bug 60231] New: WinVerifyTrust/CryptMsgControl(CMSG_CTRL_VERIFY_SIGNATURE) rejects valid Authenticode signatures whose authenticatedAttributes don't survive re-encoding round-trip

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
  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.