[jira] [Commented] (SANSELAN-17) integer overflow unhandled

["Damjan Jovanovic (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SANSELAN-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213300#comment-13213300 ] 

Damjan Jovanovic commented on SANSELAN-17:
------------------------------------------

EXIF was changed to silently ignore bad tags when not in strict mode - exceptions are only thrown in strict mode. It seems like a good idea to add this for IPTC as well.

That image has multiple APP13 segments. Even if we break instead of throw when the invalid block size happens, there is another exception later because Sanselan doesn't handle multiple APP13 segments. Even if only the first segment is returned there, it has no useful data.

On the other hand, there is some debate (http://dev.robotbattle.com/bugs/view.php?id=533 and http://uk.groups.yahoo.com/group/exiv2/message/1382) as to whether files with multiple APP13 segments are valid, because supposedly the APP13 segments can be joined together in some cases. Maybe when joined together than now invalid length of 86622 becomes valid?

                
> integer overflow unhandled
> --------------------------
>
>                 Key: SANSELAN-17
>                 URL: https://issues.apache.org/jira/browse/SANSELAN-17
>             Project: Commons Sanselan
>          Issue Type: Bug
>          Components: Format: JPEG
>    Affects Versions: 0.94-incubator
>         Environment: win32, 32 bit operating systems
>            Reporter: Greg Squires
>         Attachments: crash.jpeg
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> 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. These large numbers however cause 32bit negative signed values.
> 	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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira