6

Several dominant software vendors distribute updates over HTTP or over HTTPS with bad certificates. In general, it doesn't seem like I can expect to rely on a secure channel to ensure that an installer is not tampered with in transit.

It looks like all of the installers have valid signatures. This is a typical screen when I check the properties of an installer file:

enter image description here

The operative part of the dialog box is "This digital signature is OK." What is not clear is what portion of the file the signature is attesting to. You would expect this to be all of the file, but I haven't found a statement from Microsoft confirming that. I also vaguely recall a tweet rumoring that only parts of a file are attested to by a code signing signature.

  1. What parts of a file are checked by windows when checking whether a code signing signature is "OK"?

  2. Are there known third-party attacks that use correctly-signed installers from a trusted second party as a vector?

Improve this question

3 Answers 3

Reset to default
5

The signature is of a hash of the portion of the executable before the code signing block. Best practice is to have both the installer and the application signed.

You can study some details by looking at this:
https://msdn.microsoft.com/en-us/library/windows/hardware/gg463180.aspx

EDIT: OK, now that I'm off the mobile device and on a real keyboard, I can elaborate.

As noted in the document to which I referred you, the hash that gets signed is generated as to the entire executable file except for two excluded portions (a) the total file checksum; and (b) the certificate tables. These cannot be incorporated into the hashing because of the chicken or egg problem (e.g., these fields are dependent on the content of the attribute certificate table, and thus their values are not fixed until the certificates/signatures are prepared and appended).

As for the attack surface/scenarios, we see once again why it is so important to have good crypto primitives, and ALSO to use best practices. I suppose that in theory an attacker could create a malicious version of a software application, and then roll it into an installer and include some carefully calculated data to generate a hash collision with an existing real MD5 certificate from the application vendor, attaching that existing certificate/signature to the compromised executable. If you only checked the installer you might get fooled. This is why MD5 cannot be trusted for this sort of application anymore. It is also why, in addition to checking the installer, you should check the application program itself.

Windows 7 accepted MD5 hashes for code signing, whereas Windows 8 and up requires SHA1 or better. (For what it's worth, I dug around my program files and old installers just now and only found one from 2008 or so that used MD5 for the signature hash. 2nd edit: I take that back, I also found a relatively recent version of Winzip using MD5).

Improve this answer
3
  • You also have a trust issue. Is "Adobe Systems, Incorporated" actually the Adobe Systems you expected to sign this file, or did someone get a CA you trust (or rather, Microsoft has decided you trust) to issue them a certificate with that name? Theoretically, an attacker could substitute in their own file signed with their own digital certificate, and provided their certificate is signed by a trusted CA, it will look legit (to most people). Would you notice (and realize) if the name was "Adobe Software LLC" that it was not the right name? "Trusted Software Updates"?
    – gregmac
    Feb 11, 2015 at 18:07
  • Its a really good point. The role of CA crucial, because if they're authenticating impersonators' credentials the whole exercise is for naught. However, I suppose one could mitigate that scenario by collecting a series of files from the application provider and comparing the certificate serial numbers. If every Sony installer certificate you find says "Sony Corporation" and bears serial no. ‎17a772242e77a4970d746713723f6029, it would be suspicious to find one installer from the same era using "Sony Corp." with a different CA and some other serial no.
    – boggart
    Feb 11, 2015 at 18:14
  • I'm using a script to automate download and validation, so I suppose I could fairly easily assert that the publisher and chain of trust remain the same. I wonder how consistent the certificates used to sign code actually are from update to update.
    – alx9r
    Feb 12, 2015 at 1:28
2

Does a valid code signing certificate mean that an installer has not been tampered with in transit?

I hoped that the answer is yes, but unfortunately, no!

Proof: take a Firefox Installer.exe downloaded from mozilla.org (327 KB as of today), open it with a HEX editor, modify a few bytes around offset 328630. Save. Check: This digital signature is OK!

For more information see How can a .exe be modified and still keep a valid digital signature? and Each Firefox download has a unique identifier

I also thought this was true (taken from the accepted answer):

The signature is of a hash of the portion of the executable before the code signing block.

but the linked question proves this is unfortunately false.

Improve this answer
5
  • The accepted answer mentions that some fields are excluded from the hash. Have you verified that the field you are changing is not one of those?
    – nobody
    Mar 19, 2022 at 16:51
  • @nobody Offset 328630 is not after digital signature, I can see Digicert-related stuff at offset 329993. At which offset begins/ends the digital signature in this .exe installer?
    – tree1234
    Mar 19, 2022 at 17:18
  • @nobody Still, this answer "No" to "Does a valid code signing certificate mean that an installer has not been tampered with in transit?" is technically correct. Ok here it's still a few bytes that can be modified, but technically, we can indeed modify a .exe and still have an OK digital sig. Which is a bit surprising.
    – tree1234
    Mar 19, 2022 at 17:19
  • @nobody In the example of the Firefox installer, do you find where is the beginning/end offset for the digital signature? I am unsure where it starts exactly, would you have an idea about how to find this precisely? One thing is sure: offset 328630 is not after the digital signature, I can see Digicert-related stuff at offset 329993 which is after.
    – tree1234
    Mar 19, 2022 at 20:38
  • Yep, you're right. I was wrong. I guess CBhacking's answer to your question must have cleared this up to so extent.
    – nobody
    Mar 20, 2022 at 5:22
0

There is a difference between the certificate signature and the signature made with the certificate.

The former, which is valid, means that the Certificate Authority says the certificate you have is a legit certificate they have controlled, and the CA signature integrity allows you to check the certificate has not been tampered with. Therefore if you trust the CA, then you can trust the certificate of the site.

The latter is used to start the TLS transactions and exchange a shared key for symmetric encryption of the current session. If the handshake is able to complete, it means that the site you are communicating with owns a copy of the private key related to the certificate. But, if there is a mismatch of the domain name on the certificate and the address you are connecting to, it could mean:

  • that the website is a subsidiary of the certificate owner, and he did not bothered to have a certificate for the new domain
  • that the website stole the private key of the legitimate owner

In conclusion, such a mismatch should lead to rejection of the communication as you have no means to ensure to with whom you are talking to.

Improve this answer
2
  • 1
    This answer seems to speak to TLS communications. The question is about signed files. Can you explain how this applies to the question?
    – alx9r
    Feb 11, 2015 at 16:19
  • TL;DR: the answer is applicable to <put whatever you want to sign here>. I did not noticed the mention to "files" in your question, my bad. But the explanation remains the same. In the case of files, the file will be signed by the private key linked to the certificate (instead of the TLS handshake). I talked about TLS specifically as your second link targets a file identified by a https. Certificates are still signed by a CA to authenticate them, and you use the certificate private key to sign whatever you want.
    – M'vy
    Feb 11, 2015 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .