Chrome OS Platform: any

Steps To Reproduce:

# echo UEsFBv//7u7d3QABAAAAAAAAAAAAAA== | base64 -d > evil.zip
# fastboot update evil.zip

Expected Result:
- The libziparchive-using tool rejects the input file without assertion or crash

Actual Result:
- The libziparchive-using tool aborts due to assertion or segfaults

How frequently does this problem reproduce?
- Always

What is the impact to the user, and is there a workaround?
- Low impact, if even noticeable. A broken zip file wouldn't let the user complete the action anyway. Out of boundary read (off by one) is no security issue imho.


Please see the attached file that contains a patch to fix the issues.

In fact, two issues exist:

The first issue, assertion, can be triggered with a modified small zip file (see "Steps to Reproduce"). If the size field in the zip header states 0, the filemap would be initialized with a size of 0 which is invalid and triggers an assertion.

The second one can be triggered with a ~547 MB zip file which I did not attach for obvious reasons. The file names of zip entries are checked to be valid UTF-8, but the file_name_length can overflow the end of file, which would result in out of boundary access (the range is not checked). It takes a tricky zip header that does not contain any null-byte, so the offset and size of the zip has to be 01010101 and 01010101, therefore ending up in such a large file. It was an interesting experience to craft such a file. :)
 

Deleted: zip_archive.patch 1.2 KB

zip_archive.patch 1.2 KB Download