On Wed, 11 May 2005, Thomas NOEL wrote: > Hello, > > Le 11.05.2005 11:49, James Yonan a écrit : > >>I think there is a security issue with the crl-verify code. OpenVPN only > >>check the issuer of the CRL, but not the CRL signature. > >>If you sign a CRL with another CA (even self signed) which have the same > >>DN than the certificate issuer, OpenVPN accept it as a good CRL : the > >>server or the client do not log any error... So, an attacker can easely > >>produce such a false CRL, nobody can see the attack. > > > > I don't see how an attacker could produce a false CRL unless they had > > write access to the CRL file. > > I agree... But in theory, write access must not be sufficiant. The CRL > is signed by the CA, this must be checked. Ok : it's theory ;-) > > To clarify the situation, here is a possible example of attack: > > Imagine I'm a user of an OpenVPN network. I have a user certificate, > issued by the CA "/CN=zorglub/". I'm fired, and my certificate is > revocated by the CA. If (if, if, if...) I have write access to the CRL > file on the server, I can put a false CRL signed by a false autosigned > CA with the same DN "/CN=zorglub/". Of course, I don't revoke any > certificate in the CRL. > > Then I can access to the VPN again because the server does not check the > CRL signature.
True, but I think you're somewhat stretching the connotation of "security bug" here. If a disgruntled employee with root access tries to leave a back door on the server before security escorts him out of the building, one cannot ascribe his ability to do so as a security bug. root access, by definition, is unrestricted. No matter how much OpenVPN tries to authenticate the CRL, an attacker with root privileges could easily install a stealth backdoor on the server which would completely bypass the VPN. James
