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

> * 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
>

[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

On Tue, Aug 10, 2004 at 11:07:47AM -0500, Neil Gierman wrote:
> 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
>
> > * 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
> >

[Valdis.Kletnieks@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

iD8DBQFBGQ7acC3lWbTT17ARAlplAJ9YgvCDvneesfkcv4cz6w JyHH/SCwCfQqYW
xbA2c5kXUOIzdeqwkFuifj8=
=lFvX
-----END PGP SIGNATURE-----

--==_Exmh_-158048533P--

[Thomas Walpuski]

* Neil Gierman wrote:
> 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.

You have to distinguish between CRL retrieval (which is not really
critical) and using a CRL in the process of verifying an certificate
chain.

All parts of Microsoft's CryptoAPI use CertGetCRLFromStore with
CERT_STORE_SIGNATURE_FLAG, i.e. improperly signed CRLs won't be used in
the verification process.

So unless you're using Microsoft's CryptoAPI at a low level and you
don't know what you're doing there is no issue.

Thomas Walpuski

[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