Summary: Heap OOB read on 32-bit via integer wraparound in Buffer::ReadU8 bounds check with crafted TTC font offset.

Program: OSS VRP

URL: https://github.com/google/woff2

Vulnerability type: Memory Corruption (in a sandboxed process)

Details

BUG LOCATION

File: src/buffer.h Function: Buffer::ReadU8() Line: 85

The vulnerable bounds check is: if (offset_ + 1 > length_) { return FONT_COMPRESSION_FAILURE(); }

Combined with the unchecked offset setter at line 154: void set_offset(size_t newoffset) { offset_ = newoffset; }

And the call site in src/font.cc line 158: file->set_offset(offset);

Where offset comes from untrusted TTC font header data.

Technical Details:

The Buffer class (buffer.h) stores its read position as offset_ of type size_t. The set_offset method at line 154 allows setting this to any value without bounds validation: void set_offset(size_t newoffset) { offset_ = newoffset; }

The ReadTrueTypeCollection function in font.cc line 158 reads uint32_t offset values from the TTC header (attacker-controlled) and passes them directly to set_offset.

On 32-bit platforms where size_t is 32 bits, the attacker sets the TTC offset to 0xFFFFFFFF. When ReadU8 is subsequently called, its bounds check at buffer.h line 85 evaluates: offset_ + 1 > length_. With offset_ = 0xFFFFFFFF, the addition 0xFFFFFFFF + 1 wraps to 0 in unsigned 32-bit arithmetic. The comparison becomes 0 > length_, which is false for any non-empty buffer. The bounds check passes.

The function then executes buffer_[0xFFFFFFFF], reading 1 byte at an address 4 GB past the start of the font data. The same wraparound affects ReadU16 (offset_ + 2), ReadU32 (offset_ + 4), ReadU24 (offset_ + 3), ReadR64 (offset_ + 8), and ReadTag (offset_ + 4).

The Buffer::Read method at line 73-74 has a secondary check that is immune to wraparound: (offset_ > length_ - n_bytes). But all the typed Read functions use their own simpler check that is vulnerable.

Attack scenario

The woff2 library was used in Chrome for rendering web fonts and was deployed on billions of 32-bit Android devices. A malicious TTC font served from a web page or embedded in a document could trigger the OOB read in the font loading path, leaking process memory contents.

Since font data is typically loaded early in the rendering pipeline, the heap layout is relatively deterministic, making heap grooming feasible. The leaked memory can reveal ASLR base addresses, heap metadata, or adjacent object contents. With ASLR defeated, a second- stage font table with crafted glyph data can exploit the signed integer overflow in glyph coordinate accumulation (glyph.cc line 154) to achieve an arbitrary write, completing the RCE chain.

EXPLOIT CHAIN TO REMOTE CODE EXECUTION

1. Attacker crafts a TrueType Collection (.ttc) file containing a TTC header with an offset table entry set to 0xFFFFFFFF.

2. Victim opens the file on a 32-bit platform. This includes 32-bit Android devices (which were common when woff2 was actively deployed in Chrome), 32-bit Windows systems, and any 32-bit Linux system using a woff2-based font renderer.

3. The ReadTrueTypeCollection function reads the offset from the TTC header and calls file->set_offset(0xFFFFFFFF).

4. The subsequent ReadTrueTypeFont call invokes ReadU16 to read the font version. ReadU16 checks offset_ + 2 > length_, which is 0xFFFFFFFF + 2 = 1 > length_. For any font larger than 1 byte, this check passes.

5. ReadU16 reads 2 bytes from buffer_[0xFFFFFFFF], which is 4 GB past the buffer start. This reads from whatever is mapped at that address in the process, typically heap metadata, stack data, or shared library contents.

6. The read data is interpreted as a font version number. If it happens to match a valid version (0x00010000 or “OTTO”), parsing continues with the corrupted offset, causing further reads at addresses past the buffer.

7. For RCE, the attacker chains this with the font processing pipeline. The reads at controlled offsets can leak heap metadata (exposing ASLR base addresses). With the leaked addresses, a second-stage crafted font table causes the glyph reconstruction code to write to a controlled address, achieving arbitrary write.

8. The signed integer overflow in glyph coordinate accumulation (glyph.cc line 154) provides an additional primitive where prev_x wraps via undefined behavior, causing miscomputed glyph coordinates that can corrupt font rendering data structures.