[
https://issues.apache.org/jira/browse/SHINDIG-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679472#action_12679472
]
Louis Ryan commented on SHINDIG-906:
------------------------------------
Dont switch to getICCProfileBytes as that provides no protection. We definitely
want to protect against these kinds of overflow and having having this code
throw an error if the expected buffer length is negative due to overflow on
32bit systems is definitely a good thing. We are recovering from this exception
and simply not rewriting the image.
@Greg
Im aware of the issue where getICCProfile can cause an OutOfMemoryError through
excessively large byte[] allocations (both on 32 bit and 64 bit systems) but
this is far preferable to a buffer overrun occurring when we attempt to use
ImageIO to read the JPEG as that occurs in native code and has security
vulnerabilities. OutOfMemory errors can occaisionally be recovered from. Greg
do you have a specifc example image that is causing you headaches that is not
included in the tests.
> BasicImageRewriter bad memory allocation arguments
> --------------------------------------------------
>
> Key: SHINDIG-906
> URL: https://issues.apache.org/jira/browse/SHINDIG-906
> Project: Shindig
> Issue Type: Bug
> Components: Java
> Affects Versions: trunk
> Environment: Win32, 32bit
> Reporter: Greg Squires
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> The Basic ImageRewriter relies on Sanselan.getICCProfile, which has limited
> bounds checking. Other metadata functions are also affected.
> This function can throw an Exception in ByteSourceArray.java due to a
> negative byte[] allocation size. The length argument has been found to wrap
> when called from IccProfileParser.java.
> In 64bit machines, issues related to incorrect metadata, or ICC data can lead
> to incorrect and excess memory allocations, which often fail. These large
> numbers however modulo on 32bit and result in negative signed values.
> The shindig test JPEGOptimizerTest behaves differently on 64 bit and 32 bit
> platforms.
> Line 45 ByteSourceArray.java:
> public byte[] getBlock(int start, int length) throws IOException
> {
> if (start + length > bytes.length)
> throw new IOException("Could not read block (block
> start: " + start
> + ", block length: " + length + ", data
> length: "
> + bytes.length + ").");
> byte result[] = new byte[length];
> System.arraycopy(bytes, start, result, 0, length);
> return result;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
