5

I discovered that a signed installer package that is reported as correctly signed on Windows 7 and earlier, is reported as "corrupt" in IE10 on Windows 8.

Further investigation showed that the signature was made with MD5.

While it is entirely sensible that Microsoft drops support for MD5, I have been unable to find any references for this fact.

I also seem to remember seeing a notice about Microsoft removing support for MD5 in earlier versions soon, but I haven't been able to find that either.

Am I correct in thinking that MD5 is not supported on Windows 8? Do anyone have a reference for it? Will support for MD5 also be removed in Windows 7 and earlier?

Rasmus Faber
  • 397
  • 2
  • 11
  • It's unlikely that MS has cut MD5 support, it's more likely a bug of some kind. – GdD Sep 20 '12 at 08:33
  • I'd say, after the FLAME malware, abusing MD5 collisions on signed drivers, to escape AV software detection, that it's fairly reasonable to think that MS has dropped support for MD5. However, I don't think it's the case. – Kao Sep 20 '12 at 08:37
  • Microsoft *has* cut MD5 support for code signing. – Polynomial Sep 20 '12 at 08:45

2 Answers2

5

In Windows 7, the requirements for code signing were as follows:

  • For applications, SHA1 is preferred, MD5 is accepted.
  • For drivers, SHA1 is required.

In Windows 8, the requirements changed to the following:

  • For applications, SHA1 is required, and SHA256 is optional.
  • For drivers, SHA1 is required, and SHA256 is optional.
  • For cross-compatibility, Microsoft supports dual-signing, in which the payload is signed with both SHA1 and SHA256. On Windows 7, the old SHA1 hash will be checked. On Windows 8, the SHA256 hash will be checked.

It's not known whether this is in response to Flame, or just a standard progression of security technology.

The problem with altering the requirements in Windows 7 is two-fold. First and foremost, there are tens of thousands of existing applications signed using MD5-based certificates. Second, it's a lot of effort to modfiy the kernel, code signing utilities, Visual Studio, etc. to reflect the new requirements. However, Microsoft have (supposedly) taken steps to ensure that no internal code-signing certificates allow MD5, and have revoked offending certificates.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • Thank you. I think I confused this issue with the deprecation of 512-bit RSA keys. Would you happen to have a reference for the Windows 8 requirements? – Rasmus Faber Sep 20 '12 at 10:39
  • @RasmusFaber No confusion. See [Signing a Driver for Public Release](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967734.aspx), [Signing and Checking Code with Authenticode](http://msdn.microsoft.com/en-us/library/ms537364.aspx), [Driver Signing Policy (Windows Vista and Later)](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548231.aspx) and an [advisory blog post](http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx), in which they explain why they revoked the cert chain. – Polynomial Sep 20 '12 at 10:53
  • I can't find anything in those links about Windows 8 requiring SHA-1 or higher for code signing applications. I do not doubt that you are correct, but I would very much like something official from Microsoft to point at. (But perhaps there isn't anything). – Rasmus Faber Sep 20 '12 at 11:03
  • @Polynomial - While it does cause a problem I would rather as a developer face this problem then the horrible events if some criminal created a payload that matched and an application that appeared to be signed by me. Besides while Windows 8 will indicate the signed application is not valid, you should still be able to install and use the application, unless there is some other reason it cannot be ran. – Ramhound Sep 20 '12 at 11:34
  • @Ramhound Note that the code signing enforcement is *not* to benefit you as a developer. It's for end users. Enabling insecure code signing techniques allows the spread of malware like Flame. However, in Windows 7, they will not update the requirements, because so much existing software expects MD5 to be supported. Changing those requirements makes a serious headache for end-users, because their existing signed software won't run at all. – Polynomial Sep 20 '12 at 11:49
  • @Polynomial - Which is the reason as a developer its not a big deal to deal with the security changes. I doubt Windows 8 will REFUSE to launch sign code with an invalid signature. What is more likely is that Windows 8 will report the problem, but allow the user to choose to run the software, besides changing the game in a good way with Windows 8 is needed. – Ramhound Sep 20 '12 at 18:57
  • @Ramhound I've seen the UI for such cases. It shows two huge buttons "Do not run" and "Delete this file". At the bottom there's a little expander button for more options, in which you can report it to MS or choose to run it. It's essentially making it 100% clear to the user that it's completely unsafe. – Polynomial Sep 21 '12 at 05:51
0

signtool.exe as included with the Windows 8 SDK refuses to create MD5 signatures. signtool sign /fd md5 says:

SignTool Error: The specified algorithm cannot be used or is invalid.

But MD5 signatures created by other means, like the venerable signcode.exe, are still valid. Even Windows 10 after the deprecation of SHA-1 certificates on 1/1/16 still accepts MD5 signatures.

This 47K executable (which shows a pair of eyes tracking the mouse pointer) has an MD5 signature based on an SHA-256 certificate and with an SHA-1 timestamp dated 1/18/2016. Windows XP SP3 through Windows 10 treat this as a properly signed file even when it has the Mark of the Web.

Community
  • 1
Jan Goyvaerts
  • 281
  • 1
  • 6