[jira] [Commented] (COMPRESS-569) OutOfMemoryError on a crafted tar file

2021-03-06 Thread Fabian Meumertzheim (Jira) 


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

Fabian Meumertzheim commented on COMPRESS-569:
--

[~bodewig] Yes, feel free to use the archive and reproducer under any license 
you want. I will let the fuzzer run on the fixed version 
(https://github.com/apache/commons-compress/commit/8543b030e93fa71b6093ac7d4cdb8c4e98bfd63d)
 and report back if I should get any more findings.

> OutOfMemoryError on a crafted tar file
> --
>
> Key: COMPRESS-569
> URL: https://issues.apache.org/jira/browse/COMPRESS-569
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.21
>Reporter: Fabian Meumertzheim
>Priority: Blocker
> Attachments: TarFileTimeout.java, timeout.tar
>
>
> Apache Commons Compress at commit
> https://github.com/apache/commons-compress/commit/1b7528fbd6295a3958daf1b1114621ee5e40e83c
>  throws an OutOfMemoryError after consuming ~5 minutes of CPU on my
> machine on a crafted tar archive that is less than a KiB in size:
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/sun.nio.cs.UTF_8.newDecoder(UTF_8.java:70)
> at 
> org.apache.commons.compress.archivers.zip.NioZipEncoding.newDecoder(NioZipEncoding.java:182)
> at 
> org.apache.commons.compress.archivers.zip.NioZipEncoding.decode(NioZipEncoding.java:135)
> at 
> org.apache.commons.compress.archivers.tar.TarUtils.parseName(TarUtils.java:311)
> at 
> org.apache.commons.compress.archivers.tar.TarUtils.parseName(TarUtils.java:275)
> at 
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1550)
> at 
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:554)
> at 
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:570)
> at 
> org.apache.commons.compress.archivers.tar.TarFile.getNextTarEntry(TarFile.java:250)
> at org.apache.commons.compress.archivers.tar.TarFile.(TarFile.java:211)
> at org.apache.commons.compress.archivers.tar.TarFile.(TarFile.java:94)
> at TarFileTimeout.main(TarFileTimeout.java:22)
> I attached both the tar file and a Java reproducer for this issue.
> Citing Stefan Bodewig's analysis of this issue:
> Your archive contains an entry with a claimed size of -512 bytes. When
> TarFile reads entries it tries to skip the content of th entry as it is
> only interested in meta data on a first scan and does so by positioning
> the input stream right after the data of the current entry. In this case
> it positions it 512 bytes backwards right at the start of the current
> entry's meta data again. This leads to an infinite loop that reads a new
> entry, stores the meta data, repositions the stream and starts over
> again. Over time the list of collected meta data eats up all available
> memory.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IMAGING-279) Array sizes not checked for overflow in BmpImageParser

2021-03-02 Thread Fabian Meumertzheim (Jira) 


 [ 
https://issues.apache.org/jira/browse/IMAGING-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fabian Meumertzheim updated IMAGING-279:

Attachment: negative_array_size_exception.bmp

> Array sizes not checked for overflow in BmpImageParser
> --
>
> Key: IMAGING-279
> URL: https://issues.apache.org/jira/browse/IMAGING-279
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: BMP
>Affects Versions: 1.0-alpha2
>Reporter: Fabian Meumertzheim
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha3
>
> Attachments: negative_array_size_exception.bmp
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In BmpImageParser.readImageContents, it is not verified that 
> [imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
>  does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
> uncaught NegativeArraySizeException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IMAGING-279) Array sizes not checked for overflow in BmpImageParser

2021-03-02 Thread Fabian Meumertzheim (Jira) 


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

Fabian Meumertzheim commented on IMAGING-279:
-

The attached BMP gives me the following stack trace when loaded via  
new BmpImageParser().getBufferedImage(new ByteSourceArray(input), new 
HashMap<>());

java.lang.NegativeArraySizeException: -938762240
at 
org.apache.commons.imaging.common.BinaryFunctions.readBytes(BinaryFunctions.java:91)
at 
org.apache.commons.imaging.formats.bmp.BmpImageParser.readImageContents(BmpImageParser.java:451)
at 
org.apache.commons.imaging.formats.bmp.BmpImageParser.getBufferedImage(BmpImageParser.java:662)
at 
org.apache.commons.imaging.formats.bmp.BmpImageParser.getBufferedImage(BmpImageParser.java:643)
 !negative_array_size_exception.bmp! 

> Array sizes not checked for overflow in BmpImageParser
> --
>
> Key: IMAGING-279
> URL: https://issues.apache.org/jira/browse/IMAGING-279
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: BMP
>Affects Versions: 1.0-alpha2
>Reporter: Fabian Meumertzheim
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha3
>
> Attachments: negative_array_size_exception.bmp
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In BmpImageParser.readImageContents, it is not verified that 
> [imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
>  does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
> uncaught NegativeArraySizeException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IMAGING-279) Array sizes not checked for overflow in BmpImageParser

2021-03-01 Thread Fabian Meumertzheim (Jira) 


 [ 
https://issues.apache.org/jira/browse/IMAGING-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fabian Meumertzheim updated IMAGING-279:

Description: In BmpImageParser.readImageContents, it is not verified that 
[imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
 does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
uncaught NegativeArraySizeException.  (was: In 
BmpImageParser.readImageContents, there is no check that 
[imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
 does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
uncaught NegativeArraySizeException.)

> Array sizes not checked for overflow in BmpImageParser
> --
>
> Key: IMAGING-279
> URL: https://issues.apache.org/jira/browse/IMAGING-279
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: BMP
>Affects Versions: 1.0-alpha2
>Reporter: Fabian Meumertzheim
>Priority: Major
>
> In BmpImageParser.readImageContents, it is not verified that 
> [imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
>  does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
> uncaught NegativeArraySizeException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (COMPRESS-569) OutOfMemoryError on a crafted tar file

2021-03-01 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created COMPRESS-569:


 Summary: OutOfMemoryError on a crafted tar file
 Key: COMPRESS-569
 URL: https://issues.apache.org/jira/browse/COMPRESS-569
 Project: Commons Compress
  Issue Type: Bug
Affects Versions: 1.21
Reporter: Fabian Meumertzheim
 Attachments: TarFileTimeout.java, timeout.tar

Apache Commons Compress at commit
https://github.com/apache/commons-compress/commit/1b7528fbd6295a3958daf1b1114621ee5e40e83c
 throws an OutOfMemoryError after consuming ~5 minutes of CPU on my
machine on a crafted tar archive that is less than a KiB in size:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.base/sun.nio.cs.UTF_8.newDecoder(UTF_8.java:70)
at 
org.apache.commons.compress.archivers.zip.NioZipEncoding.newDecoder(NioZipEncoding.java:182)
at 
org.apache.commons.compress.archivers.zip.NioZipEncoding.decode(NioZipEncoding.java:135)
at 
org.apache.commons.compress.archivers.tar.TarUtils.parseName(TarUtils.java:311)
at 
org.apache.commons.compress.archivers.tar.TarUtils.parseName(TarUtils.java:275)
at 
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1550)
at 
org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:554)
at 
org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:570)
at 
org.apache.commons.compress.archivers.tar.TarFile.getNextTarEntry(TarFile.java:250)
at org.apache.commons.compress.archivers.tar.TarFile.(TarFile.java:211)
at org.apache.commons.compress.archivers.tar.TarFile.(TarFile.java:94)
at TarFileTimeout.main(TarFileTimeout.java:22)

I attached both the tar file and a Java reproducer for this issue.

Citing Stefan Bodewig's analysis of this issue:
Your archive contains an entry with a claimed size of -512 bytes. When
TarFile reads entries it tries to skip the content of th entry as it is
only interested in meta data on a first scan and does so by positioning
the input stream right after the data of the current entry. In this case
it positions it 512 bytes backwards right at the start of the current
entry's meta data again. This leads to an infinite loop that reads a new
entry, stores the meta data, repositions the stream and starts over
again. Over time the list of collected meta data eats up all available
memory.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-567) IllegalArgumentException in ZipFile.positionAtCentralDirectory

2021-02-26 Thread Fabian Meumertzheim (Jira) 


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

Fabian Meumertzheim commented on COMPRESS-567:
--

I found these bugs using https://github.com/CodeIntelligenceTesting/jazzer, 
which provides you with both the raw crashing input and a Java reproducer with 
the raw input encoded as Base64 for easier sharing (byte array literals are 
cumbersome in Java and would need more characters).

> IllegalArgumentException in ZipFile.positionAtCentralDirectory
> --
>
> Key: COMPRESS-567
> URL: https://issues.apache.org/jira/browse/COMPRESS-567
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Fabian Meumertzheim
>Priority: Major
> Attachments: crash.zip
>
>
> The following snippet of code throws an undeclared IllegalArgumentException:
> {code:java}
> byte[] bytes = Base64.getDecoder().decode("UEsFBgAAAQD//1AAJP9QAA==");
> SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes);
> try {
> ZipFile file = new ZipFile(input);
> } catch (IOException ignored) {}
> {code}
> The stack trace is:
> {noformat}
> java.lang.IllegalArgumentException: Position has to be in range 0.. 2147483647
>   at 
> org.apache.commons.compress.utils.SeekableInMemoryByteChannel.position(SeekableInMemoryByteChannel.java:94)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory32(ZipFile.java:1128)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1037)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
> {noformat}
> I also attached the input as a ZIP file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-568) NullPointerException in X5455_ExtendedTimestamp.getLocalFileDataData

2021-02-25 Thread Fabian Meumertzheim (Jira) 


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

Fabian Meumertzheim commented on COMPRESS-568:
--

Sorry, I should have tested with current HEAD as well.  I also can't reproduce 
this on 
https://github.com/apache/commons-compress/commit/1b7528fbd6295a3958daf1b1114621ee5e40e83c

> NullPointerException in X5455_ExtendedTimestamp.getLocalFileDataData
> 
>
> Key: COMPRESS-568
> URL: https://issues.apache.org/jira/browse/COMPRESS-568
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Fabian Meumertzheim
>Priority: Major
> Attachments: npe.zip
>
>
> The following snippet of code throws an undeclared NullPointerException:
> {code:java}
> byte[] bytes = 
> base64.getDecoder().decode("UEsDBAoACQAAAGu0ukYdiHewEwcDABwAYWFhVVQDAAn5ygAAUEsFBgAC/0IABQAAUEsBAh4DCgAJAP8ABbS6RgAAIAAHAAABAABQSwUGAP///wU=");
>  
> SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes); 
> try { ZipFile file = new ZipFile(input); } catch (IOException ignored) {}
> {code}
> The stack trace is:
> {noformat}
> java.lang.NullPointerException: Cannot invoke 
> "org.apache.commons.compress.archivers.zip.ZipLong.getBytes()" because 
> "this.modifyTime" is null
>   at 
> org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestamp.getLocalFileDataData(X5455_ExtendedTimestamp.java:180)
>   at 
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.mergeLocalFileDataData(ExtraFieldUtils.java:250)
>   at 
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:691)
>   at 
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.addExtraField(ZipArchiveEntry.java:573)
>   at 
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.mergeExtraFields(ZipArchiveEntry.java:903)
>   at 
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:676)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.resolveLocalFileHeaderData(ZipFile.java:1237)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:373)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
> {noformat}
> I also attached the input as a ZIP file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-567) IllegalArgumentException in ZipFile.positionAtCentralDirectory

2021-02-25 Thread Fabian Meumertzheim (Jira) 


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

Fabian Meumertzheim commented on COMPRESS-567:
--

Yes, the ZIP is clearly invalid, but I would expect a (subclass of) IOException 
here instead of an IllegalArgumentException.

> IllegalArgumentException in ZipFile.positionAtCentralDirectory
> --
>
> Key: COMPRESS-567
> URL: https://issues.apache.org/jira/browse/COMPRESS-567
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Fabian Meumertzheim
>Priority: Major
> Attachments: crash.zip
>
>
> The following snippet of code throws an undeclared IllegalArgumentException:
> {code:java}
> byte[] bytes = Base64.getDecoder().decode("UEsFBgAAAQD//1AAJP9QAA==");
> SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes);
> try {
> ZipFile file = new ZipFile(input);
> } catch (IOException ignored) {}
> {code}
> The stack trace is:
> {noformat}
> java.lang.IllegalArgumentException: Position has to be in range 0.. 2147483647
>   at 
> org.apache.commons.compress.utils.SeekableInMemoryByteChannel.position(SeekableInMemoryByteChannel.java:94)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory32(ZipFile.java:1128)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1037)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
> {noformat}
> I also attached the input as a ZIP file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (COMPRESS-568) NullPointerException in X5455_ExtendedTimestamp.getLocalFileDataData

2021-02-25 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created COMPRESS-568:


 Summary: NullPointerException in 
X5455_ExtendedTimestamp.getLocalFileDataData
 Key: COMPRESS-568
 URL: https://issues.apache.org/jira/browse/COMPRESS-568
 Project: Commons Compress
  Issue Type: Bug
Affects Versions: 1.20
Reporter: Fabian Meumertzheim
 Attachments: npe.zip

The following snippet of code throws an undeclared NullPointerException:
{code:java}
byte[] bytes = 
base64.getDecoder().decode("UEsDBAoACQAAAGu0ukYdiHewEwcDABwAYWFhVVQDAAn5ygAAUEsFBgAC/0IABQAAUEsBAh4DCgAJAP8ABbS6RgAAIAAHAAABAABQSwUGAP///wU=");
 
SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes); 
try { ZipFile file = new ZipFile(input); } catch (IOException ignored) {}
{code}

The stack trace is:

{noformat}
java.lang.NullPointerException: Cannot invoke 
"org.apache.commons.compress.archivers.zip.ZipLong.getBytes()" because 
"this.modifyTime" is null
at 
org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestamp.getLocalFileDataData(X5455_ExtendedTimestamp.java:180)
at 
org.apache.commons.compress.archivers.zip.ExtraFieldUtils.mergeLocalFileDataData(ExtraFieldUtils.java:250)
at 
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:691)
at 
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.addExtraField(ZipArchiveEntry.java:573)
at 
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.mergeExtraFields(ZipArchiveEntry.java:903)
at 
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:676)
at 
org.apache.commons.compress.archivers.zip.ZipFile.resolveLocalFileHeaderData(ZipFile.java:1237)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:373)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
{noformat}

I also attached the input as a ZIP file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (COMPRESS-567) IllegalArgumentException in ZipFile.positionAtCentralDirectory

2021-02-25 Thread Fabian Meumertzheim (Jira) 


 [ 
https://issues.apache.org/jira/browse/COMPRESS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fabian Meumertzheim updated COMPRESS-567:
-
Description: 
The following snippet of code throws an undeclared IllegalArgumentException:
{code:java}
byte[] bytes = Base64.getDecoder().decode("UEsFBgAAAQD//1AAJP9QAA==");
SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes);
try {
ZipFile file = new ZipFile(input);
} catch (IOException ignored) {}
{code}
The stack trace is:
{noformat}
java.lang.IllegalArgumentException: Position has to be in range 0.. 2147483647
at 
org.apache.commons.compress.utils.SeekableInMemoryByteChannel.position(SeekableInMemoryByteChannel.java:94)
at 
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory32(ZipFile.java:1128)
at 
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1037)
at 
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
{noformat}
I also attached the input as a ZIP file.

  was:
The following snippet of code throws an undeclared IllegalArgumentException:

{code:java}
byte[] bytes = Base64.getDecoder().decode("UEsFBgAAAQD//1AAJP9QAA==");
SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes);
try {
ZipFile file = new ZipFile(input);
} catch (IOException ignored) {}
{code}

The stack trace is:

{noformat}
java.lang.IllegalArgumentException: Position has to be in range 0.. 2147483647
at 
org.apache.commons.compress.utils.SeekableInMemoryByteChannel.position(SeekableInMemoryByteChannel.java:94)
at 
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory32(ZipFile.java:1128)
at 
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1037)
at 
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)

{noformat}

I also attached the input as a ZIP file.



> IllegalArgumentException in ZipFile.positionAtCentralDirectory
> --
>
> Key: COMPRESS-567
> URL: https://issues.apache.org/jira/browse/COMPRESS-567
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Fabian Meumertzheim
>Priority: Major
> Attachments: crash.zip
>
>
> The following snippet of code throws an undeclared IllegalArgumentException:
> {code:java}
> byte[] bytes = Base64.getDecoder().decode("UEsFBgAAAQD//1AAJP9QAA==");
> SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes);
> try {
> ZipFile file = new ZipFile(input);
> } catch (IOException ignored) {}
> {code}
> The stack trace is:
> {noformat}
> java.lang.IllegalArgumentException: Position has to be in range 0.. 2147483647
>   at 
> org.apache.commons.compress.utils.SeekableInMemoryByteChannel.position(SeekableInMemoryByteChannel.java:94)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory32(ZipFile.java:1128)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1037)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
>   at 
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
> {noformat}
> I also attached the input as a ZIP file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (COMPRESS-567) IllegalArgumentException in ZipFile.positionAtCentralDirectory

2021-02-25 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created COMPRESS-567:


 Summary: IllegalArgumentException in 
ZipFile.positionAtCentralDirectory
 Key: COMPRESS-567
 URL: https://issues.apache.org/jira/browse/COMPRESS-567
 Project: Commons Compress
  Issue Type: Bug
Affects Versions: 1.20
Reporter: Fabian Meumertzheim
 Attachments: crash.zip

The following snippet of code throws an undeclared IllegalArgumentException:

{code:java}
byte[] bytes = Base64.getDecoder().decode("UEsFBgAAAQD//1AAJP9QAA==");
SeekableInMemoryByteChannel input = new SeekableInMemoryByteChannel(bytes);
try {
ZipFile file = new ZipFile(input);
} catch (IOException ignored) {}
{code}

The stack trace is:

{noformat}
java.lang.IllegalArgumentException: Position has to be in range 0.. 2147483647
at 
org.apache.commons.compress.utils.SeekableInMemoryByteChannel.position(SeekableInMemoryByteChannel.java:94)
at 
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory32(ZipFile.java:1128)
at 
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1037)
at 
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
at 
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)

{noformat}

I also attached the input as a ZIP file.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IMAGING-279) Array sizes not checked for overflow in BmpImageParser

2021-01-14 Thread Fabian Meumertzheim (Jira) 


 [ 
https://issues.apache.org/jira/browse/IMAGING-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fabian Meumertzheim updated IMAGING-279:

Summary: Array sizes not checked for overflow in BmpImageParser  (was: 
Array sizes not checked for overflow)

> Array sizes not checked for overflow in BmpImageParser
> --
>
> Key: IMAGING-279
> URL: https://issues.apache.org/jira/browse/IMAGING-279
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: BMP
>Affects Versions: 1.0-alpha2
>Reporter: Fabian Meumertzheim
>Priority: Major
>
> In BmpParser.readImageContents, there is no check that 
> [imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
>  does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
> uncaught NegativeArraySizeException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IMAGING-279) Array sizes not checked for overflow in BmpImageParser

2021-01-14 Thread Fabian Meumertzheim (Jira) 


 [ 
https://issues.apache.org/jira/browse/IMAGING-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fabian Meumertzheim updated IMAGING-279:

Description: In BmpImageParser.readImageContents, there is no check that 
[imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
 does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
uncaught NegativeArraySizeException.  (was: In BmpParser.readImageContents, 
there is no check that 
[imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
 does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
uncaught NegativeArraySizeException.)

> Array sizes not checked for overflow in BmpImageParser
> --
>
> Key: IMAGING-279
> URL: https://issues.apache.org/jira/browse/IMAGING-279
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: BMP
>Affects Versions: 1.0-alpha2
>Reporter: Fabian Meumertzheim
>Priority: Major
>
> In BmpImageParser.readImageContents, there is no check that 
> [imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
>  does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
> uncaught NegativeArraySizeException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IMAGING-279) Array sizes not checked for overflow

2021-01-14 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created IMAGING-279:
---

 Summary: Array sizes not checked for overflow
 Key: IMAGING-279
 URL: https://issues.apache.org/jira/browse/IMAGING-279
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: BMP
Affects Versions: 1.0-alpha2
Reporter: Fabian Meumertzheim


In BmpParser.readImageContents, there is no check that 
[imageDataSize|https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=blob;f=src/main/java/org/apache/commons/imaging/formats/bmp/BmpImageParser.java;h=09d560011ebbde5ea8df65a30ea9692c2e697d17;hb=HEAD#l441]
 does not overflow. If it does, BinaryFunctions.readBytes crashes with an 
uncaught NegativeArraySizeException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IMAGING-278) IllegalArgumentException in MyLzwDecompressor

2021-01-14 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created IMAGING-278:
---

 Summary: IllegalArgumentException in MyLzwDecompressor 
 Key: IMAGING-278
 URL: https://issues.apache.org/jira/browse/IMAGING-278
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: GIF
Affects Versions: 1.0-alpha2
Reporter: Fabian Meumertzheim


The following Java snippet crashes with an IllegalArgumentException:
{code:java}
import java.io.IOException;
import java.util.Base64;
import java.util.HashMap;

import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.common.bytesource.ByteSourceArray;
import org.apache.commons.imaging.formats.gif.GifImageParser;

public class GifImageParserCrash2 {
public static byte[] btoa(String base64) {
return Base64.getDecoder().decode(base64);
}

public static void main(String[] args) {
byte[] input = btoa("AAAp/QIKACwAgAD4Kf///iIAAA==");
try {
new GifImageParser().getBufferedImage(new ByteSourceArray(input), 
new HashMap<>());
} catch (IOException | ImageReadException e) {}
}
}

{code}

The stack trace is:
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Negative initial 
size: -30877737
at 
java.base/java.io.ByteArrayOutputStream.(ByteArrayOutputStream.java:78)
at 
org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.decompress(MyLzwDecompressor.java:144)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:397)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:261)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:475)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:459)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.getBufferedImage(GifImageParser.java:840)
at GifImageParserCrash2.main(GifImageParserCrash2.java:17)
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IMAGING-277) ArrayIndexOutOfBoundsException in MyLzwDecompressor

2021-01-14 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created IMAGING-277:
---

 Summary: ArrayIndexOutOfBoundsException in MyLzwDecompressor
 Key: IMAGING-277
 URL: https://issues.apache.org/jira/browse/IMAGING-277
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: GIF
Affects Versions: 1.0-alpha2
Reporter: Fabian Meumertzheim


The following Java snippet crashes with an ArrayIndexOutOfBoundsException:
{code:java}
import java.io.IOException;
import java.util.Base64;
import java.util.HashMap;

import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.common.bytesource.ByteSourceArray;
import org.apache.commons.imaging.formats.gif.GifImageParser;

public class GifImageParserCrash1 {
public static byte[] btoa(String base64) {
return Base64.getDecoder().decode(base64);
}

public static void main(String[] args) {
byte[] input = btoa("SQAACklJAPVPAAIKACy3LAACAP8JAAD4AA==");
try {
new GifImageParser().getBufferedImage(new ByteSourceArray(input), 
new HashMap<>());
} catch (IOException | ImageReadException e) {}
}
}
{code}

The stack trace is:
{noformat}
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 4096 
out of bounds for length 4096
at 
org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.initializeTable(MyLzwDecompressor.java:72)
at 
org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.(MyLzwDecompressor.java:63)
at 
org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.(MyLzwDecompressor.java:45)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:395)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:261)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:475)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:459)
at 
org.apache.commons.imaging.formats.gif.GifImageParser.getBufferedImage(GifImageParser.java:840)
at GifImageParserCrash1.main(GifImageParserCrash1.java:17)
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IMAGING-276) ArrayIndexOutOfBoundsException in TiffDirectory

2021-01-14 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created IMAGING-276:
---

 Summary: ArrayIndexOutOfBoundsException in TiffDirectory
 Key: IMAGING-276
 URL: https://issues.apache.org/jira/browse/IMAGING-276
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: TIFF
Affects Versions: 1.0-alpha2
Reporter: Fabian Meumertzheim
 Attachments: TiffImageParserCrash.java

The following Java snippet crashes with an ArrayIndexOutOfBoundsException:
{code:java}
import java.io.IOException;
import java.util.Base64;
import java.util.HashMap;

import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.common.bytesource.ByteSourceArray;
import org.apache.commons.imaging.formats.tiff.TiffImageParser;

public class TiffImageParserCrash {
public static byte[] btoa(String base64) {
return Base64.getDecoder().decode(base64);
}

public static void main(String[] args) {
byte[] input = 
btoa("SUkqAAoCAgIAAQIIAADNAAICAgICCQ==");
try {
new TiffImageParser().getBufferedImage(new ByteSourceArray(input), 
new HashMap<>());
} catch (IOException | ImageReadException e) {}
}
}
{code}

The stack trace is:
{noformat}
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 
out of bounds for length 0  
  
at 
org.apache.commons.imaging.formats.tiff.TiffDirectory.getJpegRawImageDataElement(TiffDirectory.java:859)


at 
org.apache.commons.imaging.formats.tiff.TiffReader.getJpegRawImageData(TiffReader.java:485)

 
at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:219)

   
at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:115)

   
at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectories(TiffReader.java:108)
at 
org.apache.commons.imaging.formats.tiff.TiffReader.read(TiffReader.java:419)
at 
org.apache.commons.imaging.formats.tiff.TiffReader.readFirstDirectory(TiffReader.java:382)
at 
org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:465)
at TiffImageParserCrash.main(TiffImageParserCrash.java:17)
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IMAGING-275) NegativeArraySizeException in SofnSegment

2021-01-14 Thread Fabian Meumertzheim (Jira) 
Fabian Meumertzheim created IMAGING-275:
---

 Summary: NegativeArraySizeException in SofnSegment
 Key: IMAGING-275
 URL: https://issues.apache.org/jira/browse/IMAGING-275
 Project: Commons Imaging
  Issue Type: Bug
  Components: Format: JPEG
Affects Versions: 1.0-alpha2
Reporter: Fabian Meumertzheim
 Attachments: JpegImageParserCrash.java

The following Java snippet crashes with a NegativeArraySizeException:
{code:java}
import java.io.IOException;
import java.util.Base64;
import java.util.HashMap;

import org.apache.commons.imaging.ImageReadException;
import org.apache.commons.imaging.common.bytesource.ByteSourceArray;
import org.apache.commons.imaging.formats.jpeg.JpegImageParser;

public class JpegImageParserCrash {
public static byte[] btoa(String base64) {
return Base64.getDecoder().decode(base64);
}

public static void main(String[] args) {
byte[] input = btoa("/9j/wAAIQf//");
try {
new JpegImageParser().getBufferedImage(new ByteSourceArray(input), 
new HashMap<>());
} catch (IOException | ImageReadException e) {}
}
}
{code}

The stack trace is:
{noformat}
Exception in thread "main" java.lang.NegativeArraySizeException: -1 

   
at 
org.apache.commons.imaging.formats.jpeg.segments.SofnSegment.(SofnSegment.java:72)


at 
org.apache.commons.imaging.formats.jpeg.segments.SofnSegment.(SofnSegment.java:56)


at 
org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSegment(JpegDecoder.java:235)

  
at 
org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:91)

   
at 
org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:543)


at 
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:104)

  
at JpegImageParserCrash.main(JpegImageParserCrash.java:17)
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)