ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <>
Subject [jira] [Commented] (WSS-638) out of memory when validating XML-Signature of an encypted SOAP-Message with large attachment
Date Wed, 30 Jan 2019 15:52:00 GMT


Colm O hEigeartaigh commented on WSS-638:

[~mhaeusle] - would you consider submitting a patch or pull request for this change + I'll
take a look?

> out of memory when validating XML-Signature of an encypted SOAP-Message with large attachment
> ---------------------------------------------------------------------------------------------
>                 Key: WSS-638
>                 URL:
>             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(
> at
> at
> at
> at com.sun.crypto.provider.GaloisCounterMode.decrypt(
> at com.sun.crypto.provider.CipherCore.update(
> at com.sun.crypto.provider.CipherCore.update(
> at com.sun.crypto.provider.AESCipher.engineUpdate(
> at javax.crypto.Cipher.update(
> at javax.crypto.CipherInputStream.getMoreData(
> at
> at org.apache.wss4j.common.util.AttachmentUtils$
> at
> at
> at
> at
> at
> at org.apache.wss4j.dom.transform.AttachmentContentSignatureTransform.processAttachment(
> at org.apache.wss4j.dom.transform.AttachmentContentSignatureTransform.transform(
> at
> at
> at
> at
> at org.apache.wss4j.dom.processor.SignatureProcessor.verifyXMLSignature(
> at org.apache.wss4j.dom.processor.SignatureProcessor.handleToken(
> at org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(
> at org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(
> {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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message