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