Glyphs with LOTS of Zero Width Joiner hangs Firefox, leading to deny of service
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: ujueseo.yeou, Unassigned)
Details
(Keywords: csectype-dos)
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0
Steps to reproduce:
First, a bit of context: there is a way to combine characters with Zero Width Joiner (ZWJ) to hide stuff beyond this characters; see https://paulbutler.org/2025/smuggling-arbitrary-data-through-an-emoji/ for details.
There is actually no limit to hide characters this way. Thus, we can hide a whole text – example the full text of "Alice in Wonderland" (available here) beyond a single visible character.
So I did this using this encoder https://emoji.paulbutler.org/?mode=encode
Result is in attachment (use UTF-8) or visible here https://upload.spacefox.fr/alice_as_emoji.txt
Actual results:
FireFox hangs for several seconds (~7 seconds on a Ryzen 7 5800X3D, Ubuntu 24.04 up-to-date, Firefox 135.0.1 (64 bits) through Snap). Problem also exists on Firefox 135 for Windows 10./hto
This is also a kind of security issue as this allows hard to detect deny of service: only a character is visible but the whole tab is frozen seconds, or minutes if a character is forged with even more hidden character.
Expected results:
The character should be displayed nearly instantly.
This is a Firefox-specific issue as Chromium-based browser can display this character without noticeable lag.
If this can help:
— Terminal (tilix) can "cat alice_as_emoji.txt" instantly
— Gedit displays the file in less than 2 seconds
— LibreOffice Writer won’t event display it after several minutes and prefers to die
|
||
Comment 1•3 hours ago
|
||
Can you attach a profile from the Firefox profiler (see https://profiler.firefox.com/ ) when reproducing this?
I tried downloading the attachment and then loading that over http in a browser running the profiler but couldn't reproduce the hang. But also, the characters were all garbled so I expect that some encoding mishap must have happened. Still, that means it's not clear to me how to reproduce the problem and diagnose it further.
Moving components based on a guess as to where the problem might be, but we may need/want to move it some more...
Also available as https://share.firefox.dev/41jTaKk
Note this bug requires UTF-8 to work with provided example, otherwise there will be just garbage displayed. You can test through this URL https://upload.spacefox.fr/alice_as_emoji.txt which has correct HTTP headers – the attached version has not thus don’t bug "as expected".
To be precise if you want to reproduce 100% local: content-type: text/plain; charset=utf-8 HTTP will display the single character and trigger the bug; content-type: text/plain alone will result as garbage display.
|
||
Comment 5•28 minutes ago
|
||
As described by you (and your profiler data) this is a DOS on the child process, which isn't nice but doesn't need to be hidden as a security bug.
Several of us have tried to reproduce on Mac and Windows in various versions of Firefox (release 135.0.1 like you, plus beta and nightly) and aren't seeing anything. We have not tried our standard Linux builds to compare (I'm sure folks will now that people other than the security team can see this), but is it possible this is due to some harfbuzz modification or build config in the snap builds?
|
|
||
Updated•28 minutes ago
|
Hi,
No problem for security tag, I prefered to be sure and to avoid exposing security issue by mistake.
If this can help you, here is a profile on the exact same machine and Firefox version (135.0.1 64 bits) but dual-booted on Windows 11 (11 pro 24H2 build 2611.2894 + feature pack 1000.26100.36.0) – also available on https://share.firefox.dev/3D8p8kN
Description
•