What is CVE-2013-3900 about?

  • Windows executables (.exe, .dll, .sys, .drv and others) can be signed to prove that they (a) came from a particular developer and (b) haven’t been tampered with since they were signed. Microsoft calls their implementation of code-signing Authenticode.
  • Windows executables are signed using certificates that can be embedded in PKCS7 format within the executable files themselves (or stored in separate .cat files). The area of Windows executables that contains these certificates should only contain the PKCS7 formatted certificates and zeros to pad out the area.
  • Developers (malicious and otherwise) discovered they could store other information in the area of an executable intended only to contain certificates and zeroes, and Windows wouldn’t detect that the executable had been modified. This defeats the second purpose of signed executables mentioned above i.e. proving they haven’t been modified since they were signed.
  • Microsoft released an update in 2013 that changes the way that Authenticode verifies executables. If a signed executable contains non-zero characters as part of its certificate padding, it will be considered to have an invalid signature. However by default when you install the update it isn’t enabled. You need to opt-in by adding a Registry key called “EnableCertPaddingCheck” and then rebooting to enable it.

What does this look like inside an executable?

The Dropbox installer is an example of an executable that contains some non-zero data after their certificates, which will trigger this change in how they are handled. You can see this if you download the full installer of their software and open it in a hex editor like HxD for Windows or Hex Fiend for Mac.

At the very end of file, after the certificate data where there should just be zeroes, there is a block of data which contains an ‘appguid’, a ‘buildid’, etc.

What happens if you enable the CVE-2013-3900 fix?

The only difference I noticed on a Windows 11 install, is that the executable is no longer shown as signed. Typically if a Windows executable is signed, within the file’s Properties there will be a tab showing “Digital Signatures”. But after enabling Microsoft’s fix, the Digital Signatures tab is not shown, because Windows doesn’t consider the executable to have a valid signature.

I expected some kind of warning when running the installer after making the change, but Windows still let me run the installer quite happily and it even still said the publisher was verified.

Bit of a mixed message.

How to find files that have non-zero padding?

Microsoft doesn’t provide a tool to scan executables for non-zero padding after certificates, but security researcher Didier Stevens does provide a tool that amongst a large number of other checks on Windows executables, it looks for “Bytes after PKCS7 signature not zero”.

That tool, called AnalyzePESig, can be downloaded from this page of Didier’s website: https://blog.didierstevens.com/programs/authenticode-tools/

That ZIP files contains a number of files including the source code for the tool. However on a 64-bit version of Windows you just need the AnalyzePESig-x64.exe file that is in the x64\Release folder of the ZIP file, and on a 32-bit version of Windows you need the AnalyzePESig-x86.exe in the Release folder.

The tool has a number of parameters but for my own testing I used the command AnalyzePESig-x64.exe -e -O -s -l -v and the path I wanted it to scan like AnalyzePESig-x64.exe -e -O -s -l -v c:\users\alistair\Downloads.

-e scans each file first to see if it is an executable (ignoring file extensions), and then if it is an executable it does the full scan and adds it to the report

-O output the results to a file with a generated filename that includes the device being scanned and a timestamp

-s to recurse through directories

-l to follow reparse points, like when your desktop is repointed to a location on a server

-v to output the report in CSV format (at the moment the XML generated by the tool has a simple bug, reported in this PR on GitHub)

You can then open the resulting CSV file in Excel. By default if you just double-click one of the reports that the tool has generated Excel will make a mess of presenting the data. However if you open Excel and select File -> Open to open the file, Excel will then prompt you for details about the format of the file and you can tell it that the file is “Delimited” and uses “Semicolon” as the delimiter.

Once you have the file open the relevant columns are A that includes the file name, and AD to AG that include the analysis of the signature and padding. The most important column is “Bytes_after_PKCS7_signature_not_zero”. Any file with a number greater than zero in this column, has non-zero characters in the padding area after the signing certificates, and will be affected by the CVE-2013-3900 fix.