You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Fred Dushin (JIRA)" <ji...@apache.org> on 2008/04/10 16:56:10 UTC
[jira] Commented: (WSS-94) Security Breach : The client certificate
signature is not verified if the serial number is known in the keystore
[ https://issues.apache.org/jira/browse/WSS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587662#action_12587662 ]
Fred Dushin commented on WSS-94:
--------------------------------
Hi Fabien,
Could you please submit this as a patch, and grant ASF permission to use it?
Adding a test case as well, while not required, would be helpful (thanks for your description of how to reproduce, BTW)
Thanks!
> Security Breach : The client certificate signature is not verified if the serial number is known in the keystore
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WSS-94
> URL: https://issues.apache.org/jira/browse/WSS-94
> Project: WSS4J
> Issue Type: Bug
> Environment: WSS4J version 1.5.3
> Reporter: Fabien KOCIK
> Assignee: Ruchith Udayanga Fernando
>
> To reproduce :
> I created a root AC
> I created a sub AC certified by the root AC
> I created an object with serial number 1 and certified it with the sub AC.
> Then a created a new root AC
> I created a new sub AC certified by the new root AC
> I put the new AC and new sub AC public certificates into the WSS4J keystore and I called my service with the old object.
> WSS4J considered my object as trusted ! However, my object was not signed by my new AC.
> The problem is that WSHandler (method verifyTrust) is using serial number to extract cerificates from the keystore.
> Then it checks if the received certificate is equal to the extracted one (all is ok here).
> As the two certificates are not equals (different signature), the process continues extracting the certificate chain that should trust
> the certificate (new Sub AC and new root AC in our case).
> Then the Crypto object is requested to validate the certificates path : ok, but the array passed to validateCertPath does not contains
> the received certificate... Only the ACs certificate chain : so it never fails !
> Here is a patch that seems to solve this vulnerability :
> Index: WSHandler.java
> ===================================================================
> RCS file: /u/cvs/wss4j/src/main/java/org/apache/ws/security/handler/WSHandler.java,v
> retrieving revision 1.1
> diff -u -r1.1 WSHandler.java
> --- WSHandler.java 5 Nov 2007 16:19:35 -0000 1.1
> +++ WSHandler.java 5 Nov 2007 16:29:58 -0000
> @@ -1017,7 +1017,14 @@
>
> // Use the validation method from the crypto to check whether the subjects certificate was really signed by the issuer stated in the certificate
> try {
> - if (reqData.getSigCrypto().validateCertPath(certs)) {
> + // BEGIN - CIRSO Bug Fix - Adding received certificate to the chain ...
> + X509Certificate[] receivedPath=new X509Certificate[certs.length+1];
> + receivedPath[0]=cert;
> + int j=1;
> + for (X509Certificate trustedAuthority : certs)
> + receivedPath[j++]=trustedAuthority;
> + // END - CIRSO Bug Fix - Adding received certificate to the chain
> + if (reqData.getSigCrypto().validateCertPath(receivedPath)) {
> if (doDebug) {
> log.debug("WSHandler: Certificate path has been verified for certificate with subject " + subjectString);
> }
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org