Windows doesn't verify digital signature of CRL files

[Faro Poplar]

Hi,everybody!

Has anyone noticed that Windows doesn't verify the digital signature of CRL files (*.crl). After you modify the content of a CRL file, Windows doesn't tell you it has been tampered.

I found this problem under Windows2000/XP. Did Microsoft plan to do so or is it an OS bug?

You can test this with the following steps:

1) download a CRL file from any CA to your Windows machine, eg. http://crl.verisign.com/RSASecureServer.crl

2) double click the file "RSASecureServer.crl" in Windows Explorer, open the "Revoked List" tab. Remember the serial number of any revoked certificate, for example, the serial number of the first cert in the list is:
" 0101 CD5F A174 D413 BE0F 666A 034A 004A "

3) close the opened file "RSASecureServer.crl"

4) Re-open the file with a Hex editor (eg.ultraedit), and find the Hex String " 0101 CD5F......", modify it and save the changes.

5) double-click the file in Windows Explorer, switch to the "Revoked List" tab, and you will find the changes have been there and Windows didn't do the signature verification work!

Now the cert "0101 CD5F ..." is no longer "REVOKED" if a relying-party would make a CRL-based certificate status check.

But if you do the same thing with a certificate file(*.crt, *.cer),Windows will tell you the certificate has an invalid signature.

Any comments are welcome.

[Thomas Walpuski]

* Faro Poplar wrote:
> Has anyone noticed that Windows doesn't verify the digital signature
> of CRL files (*.crl).

Yes, I noticed that about 2 years ago. IMO this is no security issue.
CRLs are retrieved from the certificate store via CertGetCRLFromStore.
Sane use of CertGetCRLFromStore makes sure only properly signed CRLs are
used (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
seccrypto/security/certverifycrlrevocation.asp).

Thomas Walpuski

[Neil Gierman]

Correct me if I am wrong but I understood that certificate validation was
processed by the information in the certificate to be validated (CDP or
AIA extension). If the CDP location contains a valid CRL URL and that CA's
CRL is not already in cache, then the CRL is retreived from that CDP URL
in the certificate. If a person was able to inject a modified CRL into
that CDP URL, or redirect the client machine to an alternate server for
LDAP/HTTP CRL download, and CAPI is not validating signatures on CRL's
then a person could use a revoked certificate for access to systems among
other things.

While this may not be a bug I think it would be a wise security practice
to validate a signature if it is there.

Neil

[Jack Lloyd]

If Windows is not checking the signature, not only can you remove or alter
revocations, you can also add ones. For example by creating a CRL revoking all
of Verisign's root certs, and then getting it to users by either a) breaking
into Verisign's CRL servers and just putting it out there, or b) simply putting
it online somewhere and then generating a certificate that lists the location
of your fake Verisign CRL in the CDP extension and getting people to use that
cert ("Here's my S/MIME cert, just import it into Outlook..."). Assuming
Microsoft's cert stuff actually does active CRL retrival, not sure if that is
the case or not.

I would say this is a fairly major bug, given that it makes CRLs more or less
useless, all that's required to exploit it is a DNS cache poisoning attack, or
an active attack on the TCP connection when the machine retrieves the latest
CRL. The whole point of signing the CRLs is that by doing so the servers
hosting them, and the communications transfering them do not have to be
trusted.

Oddly, I couldn't find any language in RFC 3280 that actually requires
verifying the signature in a CRL. Strange.

-Jack

[Valdis.K...@vt.edu]

--==_Exmh_-158048533P
Content-Type: text/plain; charset=us-ascii

On Tue, 10 Aug 2004 07:32:40 -0000, Thomas Walpuski said:

> Sane use of CertGetCRLFromStore makes sure only ....

Yes.. and sane checking of subscripts prevents buffer overflows.

What's wrong with this picture? :)

--==_Exmh_-158048533P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBGQ7acC3lWbTT17ARAlplAJ9YgvCDvneesfkcv4cz6wJyHH/SCwCfQqYW
xbA2c5kXUOIzdeqwkFuifj8=
=lFvX
-----END PGP SIGNATURE-----

--==_Exmh_-158048533P--

[Thomas Walpuski]

* Jack Lloyd wrote:
> If Windows is not checking the signature, not only can you remove or alter
> revocations, you can also add ones.

Microsoft's CryptoAPI does check the CRL's signature. It just does not
check it on retrieval, but in the process of verifying certificates.

> Oddly, I couldn't find any language in RFC 3280 that actually requires
> verifying the signature in a CRL. Strange.

RFC 3280, 6.3.3 CRL Processing:

For each distribution point (DP) in the certificate CRL distribution
points extension, for each corresponding CRL in the local CRL cache,
while ((reasons_mask is not all-reasons) and (cert_status is
UNREVOKED)) perform the following:

[..]

(f) Obtain and validate the certification path for the complete CRL
issuer. If a key usage extension is present in the CRL issuer's
certificate, verify that the cRLSign bit is set.

(g) Validate the signature on the complete CRL using the public key
validated in step (f).

That's almost exactly what Microsoft's CryptoAPI does.

Thomas Walpuski

[Michael Howard]

CryptoAPI in Windows will always verify the CRL signature when
determining revocation status of a certificate. While
CertVerifyCertRevocation can be used to validate certificates, we
recommend developers validate certificates using CertGetCertificateChain
in their code because it will construct a certificate chain, download
all necessary CRLs and validate the certificate chain as defined by the
IETF standard (RFC 3280) on certificate validation.

Generally we recommend devs call CertGetCertificateChain and
CertVerifyCertificateChainPolicy to validate certs rather than call
WinVerifyTrust or build their own verification algorithm using APIs such
as CertGetCRLFromStore, CertGetIssuerCertificateFromStore or
CertVerifyRevocation.

Finally, the CRL UI in Windows shows you what is in the CRL. Valid or
not. But code in Windows validates the CRL when needed.

I hope that helps...

Cheers, Michael

[Writing Secure Code 2nd Ed]
http://www.microsoft.com/mspress/books/5957.asp
[Protect Your PC] http://www.microsoft.com/protect
[Blog] http://blogs.msdn.com/michael_howard