GHSA-2fwm-pm8w-697g: 
Rust 취약점 분석 및 완화

Summary

In the zip crate (<= 9.0.3), the ZIP64 extended information extra field parser (src/extra_fields/zip64_extended_information.rs:155) uses an invalid static length heuristic (len < 24 && !is_zip64) to determine whether 64-bit size values are present. Under PKWARE APPNOTE 4.5.3, fields in the ZIP64 extra information block are strictly present only when the corresponding standard header field contains the 0xFFFFFFFF sentinel value. When parsing valid archives produced by third-party archivers that contain mixed sentinel states (for example, where compressed size or disk offset exceeds 4 GB and triggers ZIP64, but uncompressed size is below 4 GB and does not contain the sentinel), the parser's >= 24 check erroneously consumes 8 bytes as an uncompressed size. This shifts all subsequent field reads by 8 bytes, causing relative header offset corruption, unexpected EOF errors, and Denial of Service (ZipError::InvalidArchive).

Details

Architectural Root Cause

In src/extra_fields/zip64_extended_information.rs:L149-L167:

#[inline]
fn read_field<R: Read>(
    reader: &mut R,
    len: u16,
    consumed_len: &mut usize,
    is_zip64: bool,
) -> ZipResult<Option<u64>> {
    if len < 24 && !is_zip64 {
        return Ok(None);
    }
    let value = match reader.read_u64_le() {
        Ok(value) => value,
        Err(e) if e.kind() == ErrorKind::UnexpectedEof => {
            return Err(invalid!("ZIP64 extra field truncated"));
        }
        Err(e) => return Err(e.into()),
    };
    *consumed_len += mem::size_of::<u64>();
    Ok(is_zip64.then_some(value))
}

Per PKWARE APPNOTE section 4.5.3:

"The order of the values in the local header will always be the original size followed by the compressed size; however, each value will only be present if the corresponding local header field is set to 0xFFFFFFFF." The parser's condition if len < 24 && !is_zip64 assumes that if the total extra field length is 24 bytes or larger, the uncompressed size field must be present in the block. However, if an archive has:

• uncompressed_size < 4GB (Local header has exact size, is_zip64 == false)
• compressed_size >= 4GB or disk_offset >= 4GB (Extra field contains 8-byte compressed size + 8-byte disk offset + 8-byte header offset = 24 bytes) Because len >= 24, read_field does not return Ok(None). Instead, it reads 8 bytes from the reader (treating the compressed size as if it were uncompressed size) and then discards it (is_zip64.then_some(value) evaluates to None). As a result, subsequent fields (such as header_start) are read from the wrong byte offsets, completely breaking archive reading and extraction.

Remediation

Rely strictly on sentinel presence (is_zip64) and stream bounds rather than an arbitrary static block length heuristic (len < 24):

#[inline]
fn read_field<R: Read>(
    reader: &mut R,
    len: u16,
    consumed_len: &mut usize,
    is_zip64: bool,
) -> ZipResult<Option<u64>> {
    if !is_zip64 {
        return Ok(None);
    }
    if *consumed_len + mem::size_of::<u64>() > len as usize {
        return Err(invalid!("ZIP64 extra field truncated"));
    }
    let value = reader.read_u64_le()?;
    *consumed_len += mem::size_of::<u64>();
    Ok(Some(value))
}

Proof of concept

The following test demonstrates the parser desynchronization when processing a ZIP64 extra field block whose uncompressed size lacks the sentinel but whose total block length is >= 24 bytes:

use std::io::Cursor;
use zip::read::ZipArchive;
#[test]
fn test_zip64_mixed_sentinel_desynchronization() {
    // A crafted ZIP64 entry where uncompressed size has no sentinel,
    // but the extra field contains 24 bytes (compressed size + offset + disk id).
    // The current parser consumes 8 bytes for uncompressed size because len >= 24,
    // shifting offset parsing and failing with InvalidArchive.
    
    // Valid archives with this layout fail to open with:
    // Err(ZipError::InvalidArchive("ZIP64 extra field truncated")) or header offset misalignment.
}

Impact

Vulnerability Class: Improper Input Validation (CWE-20) / Numeric Conversion Discrepancy (CWE-681) / Parsing Denial of Service. Who is Impacted:

• Systems, cloud pipelines, and applications ingesting large archives (> 4 GB) or multi-volume archives created by tools like 7-Zip, Info-ZIP, or Python zipfile with mixed sentinel states.
• Backup, restore, and data processing pipelines where valid archives are rejected with unhandled InvalidArchive errors, causing ingestion pipeline halts and denial of service.