Mechanism

Firefox sanitizes web fonts through OTS before use. Three independent defects line up so that a crafted font leaves an uninitialized-heap gap inside the sanitized output and content can read it back:

1. OTS output allocator never zeroes. The expanding output stream grows with a raw reallocator (moz_xrealloc) that does not zero-fill new space.
2. Seek does not zero the skipped span. A cmap format-14 subtable with a large nonDefaultUVSOffset makes OTS seek its output stream forward when it re-serializes the sanitized font. The skipped span between the written bytes and the seek target is handed to the caller carrying uninitialized heap, and forget() sizes the buffer to the highest offset reached.
3. format-4 glyph lookup bounds-checks the wrong length. The format-4 lookup bounds-checks against the remainder of the whole cmap table rather than the subtable, so a segment whose idRangeOffset runs off the end of the format-4 data still passes the check and reads into the neighbouring subtable's uninitialized bytes.

The crafted font pairs a format-4 subtable, whose last segment (0xFFFF) uses an odd, overrunning idRangeOffset, with a format-14 subtable carrying a large nonDefaultUVSOffset, plus maxp.numGlyphs = 65535 and a distinct hmtx advance per glyph id (advance == glyph id). Measuring U+FFFF therefore resolves to a glyph id read from the uninitialized gap, and its advance width, readable from script, discloses about two bytes of heap per measurement over a roughly 64 KB window.

Threat model

An ordinary web page serves the crafted font through @font-face and calls ctx.measureText("￿"). No click, permission, extension, or pref change is required. OTS runs in-process and is not among the sandboxed libraries, so the disclosed bytes are content-process heap that may contain pointers or secrets.

Files

Prerequisites

1. A vulnerable build: Firefox before 154 or ESR before 140.14. The writeup analysis uses Firefox 140.9.0esr; download the matching platform build from the official Mozilla archive at https://ftp.mozilla.org/pub/firefox/releases/140.9.0esr/.
2. Python with fontTools and brotli, to build the font:
   root@kitploit:~

   pip install fonttools brotli
   

Build and run

Then open trigger.html in the vulnerable build, from a file:// path or a local static server you control, and click Measure.

Expected result

• Vulnerable build (before 154 / ESR 140.14): U+FFFF resolves to a non-zero glyph id derived from the uninitialized gap, and the reported advance varies from run to run. Each measurement recovers about two bytes of process heap.
• Fixed build (154 / ESR 140.14 and later): U+FFFF resolves to glyph id 0 (.notdef) and the advance is 0. No gap is leaked, because the output stream is zeroed and the format-4 lookup is bounded to its own subtable.

Verification status

• Done in this environment: make_font.py was executed here with fontTools 4.63.0 and produced leak.otf (393816 bytes) and leak.woff (132372 bytes). The generated font was parsed back from raw bytes and every crafted ingredient was confirmed: maxp.numGlyphs = 65535, hhea.numberOfHMetrics = 65535, a distinct hmtx advance per glyph id (advance == glyph id), two cmap subtables (platform 3 encoding 1 format 4, and platform 0 encoding 5 format 14), the format-4 last segment endCode = 0xFFFF with an odd overrunning idRangeOffset = 0x4001, and the format-14 nonDefaultUVSOffset = 0x8000.
• NOT done in this environment: no vulnerable Firefox build is present here, so the actual leak was not observed, triggered, or captured. The font was not loaded into a vulnerable build and no heap bytes were disclosed. Run trigger.html yourself against a local vulnerable build to observe the leak. This package demonstrates the crafted input and the read-back path; it is not a weaponized exploit and includes no controlled code-execution primitive.

Scope and ethics

This targets a locally downloaded build with synthetic, self-generated font data, for a writeup of the author's own reported and already patched CVE. It does not attack any live or third party service.