[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    [jira] [Commented] (WSS-638) out of memory when validating XML-Signature of an encypted SOAP-Message
From:       "Cosmin Baciu (Jira)" <jira () apache ! org>
Date:       2019-12-20 11:20:00
Message-ID: JIRA.13203767.1544546426000.355188.1576840800224 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/WSS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000827#comment-17000827 \
] 

Cosmin Baciu commented on WSS-638:
----------------------------------

[~mhaeusle]  Did you find a solution to this issue? Thanks.

> 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
> Priority: Major
> 
> 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
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]