Keypoints
- Researcher Malcolm Stagg identified CVE-2024-0333, a vulnerability in Chromium’s handling of CRX (ZIP-based) extension files.
- The attack injects a ZIP EOCD64 token into the CRX header so Minizip locates the malicious archive when searching the last 64 KB of the file.
- Minizip’s search order (EOCD64 first, then EOCD) and the 64 KB search limit make CRX files under ~64 KB vulnerable to this embedding technique.
- Stagg built a PoC Python script that prepends a ZIP payload into a CRX header and demonstrated changing an extension’s behavior (banner modification).
- Direct local privilege escalation proved impractical due to signed CRX sizes, but enterprise-managed extension updates from internal servers could be spoofed to deliver the malicious CRX.
- The vulnerability was reported to Google and fixed in the Chromium source and Chrome stable release 120.0.6099.216.
- Relevant components and artifacts include the CRX file format, Chromium’s Minizip (unzOpenInternal), and the EOCD/EOCD64 ZIP structures.
MITRE Techniques
- [T1195] Supply Chain Compromise – Abuse of enterprise extension update mechanism by spoofing an internal update server so Chrome downloads a maliciously modified but still-validly signed extension: ‘…it will download the maliciously modified extension from the attacker’s device…the employee’s laptop will upgrade to the malicious extension.’
- [T1553.002] Code Signing – Leveraging a valid CRX signature to bypass integrity checks by embedding a malicious ZIP payload in the CRX header so the signed file still appears legitimate: ‘Because it still contains a valid signature, the employee’s laptop will upgrade to the malicious extension.’
- [T1203] Exploitation for Client Execution – Crafting a specially formed archive (inserting an EOCD64 token into the CRX header) to influence Minizip’s archive selection and execute attacker-controlled extension code: ‘I could embed my payload into the CRX file and change the banner.’
- [T1068] Exploitation for Privilege Escalation – Attempting to use the elevation service workflow to run an elevated executable by bypassing CRX signature validation and decompression checks: ‘…I realized it would be difficult to find a flaw…how the service was designed to ensure that only trusted executable files were elevated.’
- [T1557] Adversary-in-the-Middle – Intercepting or spoofing network update traffic (e.g., in a coffee shop) to serve a modified extension from a locally controlled server matching the enterprise update host: ‘A local attacker…sets up their IP or host name to match the company’s internal update server.’
Indicators of Compromise
- [CVE] referenced vulnerabilities – CVE-2024-0333, CVE-2022-32427 (and CVE-2022-32972)
- [File name / artifact] example signed CRX used in testing – CodeRed.crx3 (GitHub test artifact)
- [URLs / domains] relevant resources and exploit disclosure – readme.synack.com/exploits-explained-zip-embedding-attack-on-google-chrome-extensions, source.chromium.org (Chromium patch)
- [Software component] library/function referenced – Minizip (unzOpenInternal / unz64local_SearchCentralDir64), Chromium elevation_service
Rewritten technical summary:
The CRX format used by Chrome extensions is a ZIP archive with a prepended header that contains signatures; the header itself is largely unverified. Chromium uses the Minizip library to decompress CRX archives; Minizip searches for ZIP end-of-central-directory markers starting from the file end and checks for the ZIP64 (EOCD64) structure before falling back to the standard EOCD. Because Minizip only searches the final 64 KB of a file, a specially crafted CRX header can contain an EOCD64 token and a ZIP payload that Minizip will treat as the archive’s central directory.
Stagg implemented a Python tool to inject a ZIP payload (with a valid EOCD64) into a CRX header and created a malicious extension payload to demonstrate control over extension behavior. The technique succeeds when the target CRX’s ZIP archive data falls within Minizip’s 64 KB search window. While many signed CRX files and Chromium components were too large to be exploited for local privilege escalation, enterprise-managed extension update workflows that fetch CRX files from internal servers can be abused: an attacker who can spoof the internal update host (for example on a local network) can serve the modified but still-signed CRX and cause Chrome to install the malicious extension.
Stagg reported the issue to Google, which patched the Minizip/CRX handling in Chromium and released the fix in Chrome 120.0.6099.216.
Read more: https://readme.synack.com/exploits-explained-zip-embedding-attack-on-google-chrome-extensions