Microsoft’s Revocation of the Verisign Class 3 Public Primary G5 Root Cert | Hacker News Reader

Microsoft’s Revocation of the Verisign Class 3 Public Primary G5 Root Cert

airlockdigital.com

124 pointscampuscodi16 comments

> I’m also surprised at how little noise this change made even within the information security community. It speaks volumes at how little digital signatures are used to proactively enforce the integrity of software at load time within the majority of the ecosystem (again kudos to Intuit).

Or more likely anybody caring about signatures would have updated the binaries already well before the 2019 date when these certs were supposed to be distrusted.

How would they have known that those certificates got distrusted? The article says the certs in question were not on any known revocation list.

https://learn.microsoft.com/en-us/security/trusted-root/2019... and https://www.microsoft.com/en-us/security/blog/2018/10/04/mic... both list the cert in question

I don't get it. How in this story is airlock digital using a certificate signed by a root that was supposed to be disabled years ago but incorrectly disabled only recently? Like where did they get such a certificate? Nobody is supposed to have issued a cert like this post 2018.

I think the situation is:

1. Executable file X is created no later than 7 Feb 2020 23:59:59.

2. X is signed using a code signing certificate J issued by "VeriSign Class 3 Code Signing 2010 CA"[1] and with a validity no later than 7 Feb 2020 23:59:59.

3. X is counter-signed by a public time-stamping service (see RFC3161[2]) no later than 7 Feb 2020 23:59:59.

4. Even if code signing certificate J expires, Windows will continue to allow the execution of X because it is counter-signed by a trusted time-stamping service which attests that X existed at a point in time when the code signing certificate J was valid. Assuming SHA256 isn't broken, an attacker can't just throw millions of SHA256 hashes at a public time-stamping service and then hope to produce at a later date an executable that collides with one of the prior counter-signed/timestamped SHA256 hashes.

5. Windows always checks that X is signed with a valid certificate such as J, regardless of expiry dates and presence of a counter-signature/timestamp. Removal of trust in "VeriSign Class 3 Code Signing 2010 CA" means this validation of X fails, respite X still having a valid counter-signature/timestamp.

6. QuickBooks had a component QBWebConnector.exe that was signed prior to 7 Feb 2020 23:59:59 by a code signing certificate issued by "VeriSign Class 3 Code Signing 2010 CA". Even though "VeriSign Class 3 Code Signing 2010 CA" has already expired, the counter-signature from a public time-stamping service has allowed Windows to continue to execute QBWebConnector.exe.

7. Windows no longer trusts "VeriSign Class 3 Code Signing 2010 CA" and therefore, the old QBWebConnector.exe created and signed before 7 Feb 2020 23:59:59 cannot be executed. It's irrelevant whether QBWebConnector.exe is counter-signed by a public time-stamping service.

[1] SHA256:D0F90BBF6EE8629E4A31CFDBAA2202E324AF2F5F456967DD83CA5B3684C34297 (https://crt.sh/?id=163359911)

[2] https://www.ietf.org/rfc/rfc3161.txt

Thanks, that was a very helpful explanation.

The problem is program executables are signed with digital certificates. So long as they were signed during the valid certificate period, they are supposed to remain signed forever. Revoking an expired base certificate like this is a huge deal and breaks a lot of software.

Airlock is security software. It's not their stuff that is failing -- they are dealing with reports about the issue and letting the world know what they've found.

Airlock is not using anything as far as I can tell, they are warning their customers that if they are using old binaries, that are signed with the revoked key, that airlock or windows (unsure) will now complain about it.

> Over the coming months Airlock Digital customers may notice an elevated occurrence of files reporting ‘(invalid certificate chains)’ over the coming months, for software that was signed between 2006 – 2017 with revoked certificate chain.

As Airlock seems to be software intended to allowlist the execution of binaries, it would make sense that they pick up on the user running binaries signed with revoked certs.

I think for code signing signatures, it's common to cache successful validation status beyond certificate expiration because it's not exactly easy to renew file signatures. So things were fine with expired certificates until the revocation. For certain revocation events, you absolutely want to invalidate past signatures and cached validation status along with them. But maybe not for this one, hard to tell.

The way it's meant to work is that the revocation date of a certificate is stored explicitly, and signatures are timestamped so you continue trusting signatures that pre-date that revocation date. Because that's supposed to be the moment the private key behind the cert became leaked or untrustworthy.

However, Microsoft aren't doing this (their code signing ecosystem is frankly a mess compared to Apple's). Instead they're ignoring the timestamps in the signatures and breaking old binaries. Not cool.

  And for VeriSign Class 3 Public Primary Certification Authority – G5 was
  supposed to be distrusted by Microsoft on May 21st 2019.

  Here is the DigiCert link for your reference: https://knowledge.digicert.com
  /alerts/symantec_root_distrust.html

  However, Microsoft remains trusting this Root certificate until Aug 23rd 2023.
  And distrusted this root certificate yesterday.

Why did it take 4 years?

the author made a guess in the next paragraph:

    When it comes to SSL certificates this change entirely makes sense, however for file trust this is problematic, as previously signed files can’t simply have the certificate updated on them in the same way websites can. This is likely why Microsoft trusted this root certificate for much longer in Microsoft Windows than browser vendors did.

But until we hear from Microsoft, I guess we won't know for sure.

Interesting. If I understand correctly, this will render some hardware whose drivers were signed with that certificate unusable. Very expensive, hard-to-replace hardware in my company's case.

Nobody seems to be talking about an outrageous act of value destruction on Microsoft's part, so maybe I'm interpreting it wrong.

This Reddit thread has a script with a workaround: https://www.reddit.com/r/sysadmin/comments/15ysxgs/applicati...

There are comments saying it's worked on several Quickbooks integrations.

Regarding hardware drivers, I _think_ the same fundamental process of removing signatures should work, but you'll get a UAC prompt to force installation of an unsigned driver.

I'm not as familiar with driver signature enforcement though, so take that with a grain of salt.

P.S: I still have running XP installs for some $300k industrial hardware. It could be worse...

Hashes of known good drivers should be whitelisted explicitly if they are known to have been signed correctly before revocation. Direct trust should trump a PKI here.

I wish Verisign could run their services properly, instead of just making business by hiking the .com and others (while wages of engineers is actually plummeting).

Do they just focus on cash cows, or do they have other products in store nowadays ?

Reply on news.ycombinator.com