verify fails on certain PE files about signify HOT 6 CLOSED

I am also having a similar error while performing checks on some files.

For example OneDrive from Microsoft: https://go.microsoft.com/fwlink/p/?LinkId=248256

It is validly signed by Microsoft: VirusTotal Signing Info

from signify.

It looks like v0.1.5 is working fine.

from signify.

This probably has to do with the change to pyasn1-modules. If you could figure out what the difference is between those and the ones we had in 0.1.5, that would be great. Also it would be helpful to know why these particular samples fail; what are they using that causes this issue?

from signify.

It appears that it is the implementation of #6 that's the culprit. You wouldn't have noticed the issues before because we simply ignored those timestamps. I'll take a look as soon as I'm able to

from signify.

It appears that it is the implementation of #6 that's the culprit. You wouldn't have noticed the issues before because we simply ignored those timestamps. I'll take a look as soon as I'm able to

Have you found the issue?

from signify.

I started debugging whois.exe, which contains a RFC5652 SignedData DER-encoded object in the attribute with OID 1.3.6.1.4.1.311.3.3.1. The extracted binary data is attached here

When parsing this structure, something goes wrong. This appears to happen because
SignedData.certificates (a CertificateSet with CertificateChoices elements) contains three elements: two untagged elements (being a certificate in CertificateChoices terms) and a third tagged attribute with tag 1. This would mean it's a v1AttrCert of type AttributeCertificateV1, according to RFC5652 section 10.2.2.

However, the structure is not actually a AttributeCertificateV1, rather adhering to AttributeCertificateV2 (as can be seen as the version inside the structure is integer 1 (which is v2, go figure...)).

The relevant part is shown below, annotated with field names for clarity:

SEQUENCE (5 elem)  # SignedData
  INTEGER 3  # version
  SET (1 elem)  # digestAlgorithms
  SEQUENCE (2 elem)  # encapContentInfo
  [0] (3 elem)  # certificates
    SEQUENCE (3 elem)  # certificate
    SEQUENCE (3 elem)  # certificate
    [1] (3 elem)  # v1AttrCert
      SEQUENCE (7 elem)  # acInfo
        INTEGER 1  # version (1 = v2)
        SEQUENCE (2 elem)  # v1: subject / v2: holder
        [0] (1 elem)  # issuer
        SEQUENCE (2 elem)  # signature
        INTEGER 3785039085  # serialNumber
        SEQUENCE (2 elem)  # attCertValidityPeriod
        SEQUENCE (2 elem)
      SEQUENCE (2 elem)  # signatureAlgorithm
      BIT STRING (1024 bit)  010000111000000001110000000001101001010110010011000010011001000000101…  # signature
  SET (1 elem)  # signerInfos

The schema above can be reproduced by using https://lapo.it/asn1js/ and uploading the attached binary blob.

I have no clue why this is happening. Perhaps they are following another RFC for this structure that specifically changes how we should interpret this ASN.1 structure, or this is simply an error that is somehow caught by Microsoft's parsers.

from signify.