[ http://issues.apache.org/jira/browse/WSS-33?page=all ]
Thomas Leonard updated WSS-33:
------------------------------
Attachment: sig-security.patch
[ This patch was previously sent privately on Mon, 23 Jan 2006 ]
Attached is a patch to fix this security problem. It changes the WSS4J API to
return the set of signed wsu:Id values instead of the signed elements' QNames
(I removed the old interface completely to force people to fix their programs).
Notes:
- It does not check that the Body is signed. It merely makes it possible for
another handler to check this. Both client and service should check the signer
of the Body (using the new ensureSignedTogether() method).
- For an RPC call, the client should normally also check that the reply is from
the service it tried to contact (e.g., by comparing the Common Name from the
certificate's subject with the host part of the Call's endpoint address).
- Possibly, we should default to enforcing this simple policy (the Body must
always be signed), since it's what most people will require.
- This patch is against subversion revision 370794.
Legal issues:
The patch adds a NOTICE file and changes the copyright headers on the files I
changed to "Copyright 2003-2006 The Apache Software Foundation, or their
licensors, as appropriate". We copied this wording from Apache jackrabit, e.g.:
http://svn.apache.org/viewcvs.cgi/incubator/jackrabbit/trunk/jackrabbit/src/main/java/org/apache/jackrabbit/core/lock/XALock.java?view=markup
This was suggested to us by Davanum Srinivas:
http://issues.apache.org/jira/browse/ADDR-10
PS: If you commit this to subversion, please record that it came from
"University of Southampton IT Innovation Centre" in the log message. Thanks!
> Signature checking vulnerability
> --------------------------------
>
> Key: WSS-33
> URL: http://issues.apache.org/jira/browse/WSS-33
> Project: WSS4J
> Type: Bug
> Reporter: Thomas Leonard
> Assignee: Davanum Srinivas
> Attachments: sig-security.patch
>
> [ This vulnerability was reported privately by email on Fri, 13 Jan 2006.
> Making it public at the request of Davanum Srinivas. ]
> Summary: given an example of a SOAP message signed (and optionally encrypted)
> by some user, an attacker can invoke any method on any WSS4J-protected
> web-service and authenticate as that user, despite not having their private
> key. A suitable example message can be acquired either by sniffing (e.g.,
> with tcpflow) or by waiting for users to invoke one of my own web services.
> This attack has been tested using the sample SecBindingImpl service provided
> with WSS4J.
> Full description:
> When WSS4J checks the signature on an incoming message, it records the QNames
> of the elements which were signed. Typically, this will just be
> [<soap:Body>]. Services are expected to check this results vector to ensure
> that the body was signed, and to discover the identity of the signer.
> The problem is that only the QName of the element is provided; if the message
> contains multiple elements with the same QName, it is not possible to tell
> whether the required elements were signed. For example, consider this genuine
> message:
> <env>
> <head>
> <wsa:To>Werner</wsa:To>
> <sig ref='#1'>Signed Thomas</sig>
> </head>
> <body id='1'>
> signed-and-encrypted-data
> </body>
> </env>
> If an attacker gets hold of this message, they can trivially forge a new
> message by moving the original body into the header (or anywhere else
> out-of-the-way) and then creating a new unsigned body without an id:
> <env>
> <head>
> <wsa:To>Werner</wsa:To>
> <sig ref='#1'>Signed Thomas</sig>
> <body id='1'>
> signed-and-encrypted-data
> </body>
> </head>
> <body>
> <malicious-operation/>
> </body>
> </env>
> When WSS4J checks the signature, it finds the body with id='1' and verifies
> the signature. It then records that <body> was correctly signed by Thomas.
> Axis then invokes the malicious operation in the real <body>. When the
> service checks, it thinks that the malicious operation was signed by Thomas.
> Note that simply ensuring a message has only one <body> element is not
> sufficient, since often other elements also need to be signed (e.g., endpoint
> reference types) and there may be many of these.
> Solution (I will attach a patch shortly):
> - Instead of recording QNames, record the wsu:Id values.
> - Ensure that wsu:Id values are unique.
> - In an additional axis handler, get the wsu:Id of the real <body> element
> and find a signature with that Id. If multiple elements must be signed, find
> a single signature over all of them.
> WSS4J should probably default to checking that the real SOAP body is signed
> and store its signer on the Axis message context, to provide a
> secure-by-default configuration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
