Michael Haeusler created WSS-638:
------------------------------------
Summary: out of memory when validating XML-Signature of an
encypted SOAP-Message with large attachment
Key: WSS-638
URL: https://issues.apache.org/jira/browse/WSS-638
Project: WSS4J
Issue Type: Bug
Components: WSS4J Axis Integration
Affects Versions: 2.2.1
Reporter: Michael Haeusler
Assignee: Colm O hEigeartaigh
I have to process a SOAP message with a binary attachment, where XML-Encryption
and XML-Signature are applied to the SOAP-Header and attachment
(SOAP-with-Attachments)
everything works just fine when the attachment size fits into the JVM memory,
however the attachment can get larger than 1GB and this results in the
following stacktrace:
{code:java}
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3236)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
at com.sun.crypto.provider.GaloisCounterMode.decrypt(GaloisCounterMode.java:498)
at com.sun.crypto.provider.CipherCore.update(CipherCore.java:772)
at com.sun.crypto.provider.CipherCore.update(CipherCore.java:671)
at com.sun.crypto.provider.AESCipher.engineUpdate(AESCipher.java:380)
at javax.crypto.Cipher.update(Cipher.java:1831)
at javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:132)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:239)
at org.apache.wss4j.common.util.AttachmentUtils$1.read(AttachmentUtils.java:528)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at
org.apache.wss4j.dom.transform.AttachmentContentSignatureTransform.processAttachment(AttachmentContentSignatureTransform.java:211)
at
org.apache.wss4j.dom.transform.AttachmentContentSignatureTransform.transform(AttachmentContentSignatureTransform.java:115)
at
org.apache.jcp.xml.dsig.internal.dom.DOMTransform.transform(DOMTransform.java:159)
at
org.apache.jcp.xml.dsig.internal.dom.DOMReference.transform(DOMReference.java:443)
at
org.apache.jcp.xml.dsig.internal.dom.DOMReference.validate(DOMReference.java:371)
at
org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.validate(DOMXMLSignature.java:265)
at
org.apache.wss4j.dom.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:373)
at
org.apache.wss4j.dom.processor.SignatureProcessor.handleToken(SignatureProcessor.java:233)
at
org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:340)
at
org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:251)
{code}
I have debugged the library and found that there is a fundamental problem in
org.apache.wss4j.dom.transform.AttachmentContentSignatureTransform
{code:java}
protected Data processAttachment(XMLCryptoContext context, OutputStream os,
String attachmentUri, Attachment attachment) throws TransformException {
try {
//try to reuse the inputStream in the hope that the provided inputStream
is backed by a disk storage
InputStream inputStream = attachment.getSourceStream();
if (!inputStream.markSupported()) {
inputStream = new BufferedInputStream(inputStream);
}
inputStream.mark(Integer.MAX_VALUE); //we can process at maximum 2G with
the standard jdk streams
{code}
there are two problems with this code:
# the inputStream.mark() causes the BufferedInputStream to grow up to 2GB
I have worked around this by providing a custom BufferedInputStream that uses a
disk storage backend, so that no memory is used. this fixes the problem for the
opposite direction where the same SOAP messages are created.
# for validation case there is no way to create a workaround, because my
attachment stream is automatically wrapped in an anonymous CipherInputStream in
org.apache.wss4j.dom.util.EncryptionUtils.decryptAttachement(String, String,
Element,SecretKey, String, CallbackHandler)
which causes a new BufferedInputStream to be wrapped around it, as shown in the
source code above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
