RFR: 8313765: Invalid CEN header (invalid zip64 extra data field size) [v3]

[Volker Simonis]

On Mon, 14 Aug 2023 18:49:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add newline

There's one final thing I want to mention. Your current test cases (i.e. the corrupted zip-files in `ReadNonStandardExtraHeadersTest.`) only reproduce the problem with `ZipFile` but not with `ZipFileSystem`. That's because of a slightly different logic in [`ZipFileSystem$Entry::readExtra()`](https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java#L3081) because of which the error will only be triggered if the `ZIP64_EXTID` Extra Block will be followed by another Extra Block. So we need a Zip file with a 0-length ZIP64_EXTID Extra Block followed by another Extra Block in order to trigger the issue. 

I've therefore attached a zip file (`ZeroLengthZIP64EXTID.zip`) which was created by ANT 1.10.7 from a directory containing a single, zero-length file and the following `build.xml` file:

<project name="ZipFiles" default="zip">
    <target name="zip">
        <zip destfile="/tmp/output.zip" zip64Mode="always" createUnicodeExtraFields="always">
            <fileset dir="/tmp/testfiles" includes="**/*" />
        </zip>
    </target>
</project>

- `zip64Mode="always"` is required in order to produce a `ZIP64_EXTID` Extra Field with zero length (which triggers the problem).
- `createUnicodeExtraFields="always"`  is required in order to produce a second Extra Field after `ZIP64_EXTID`.

I think it would be good if you could add that as test case as well.
[ZeroLengthZIP64EXTID.zip](https://github.com/openjdk/jdk/files/12338707/ZeroLengthZIP64EXTID.zip)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677913675