1793676 - (CVE-2022-45416) Potential keystroke side-channel leakage

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Andrew McCreight [:mccr8]]

I noticed a recently-public Chromium security issue involving possible cross-process leaking of information about keystrokes. The basic issue is something like, keyboard events have strings like "KeyA" associated with them that are at fixed, known, and widely-spread addresses. This means that using Prime+Probe kind of cache attacks you can maybe figure out which keys are being pressed.

Nika thinks we could be affected by the same issue, because the top level event table contains pointers to strings which the linker could put wherever, but we could also fix this by doing what the GK atoms stuff does that globs all of the strings together in a giant table. Chrome worked around it by dynamically generating the strings at runtime.

It sounds like a Chromium person thought a packed string table isn't sufficient: "this seems inevitable even with a closely packed string table, since the granulraity of the attack is ~cache-lines?".

I'm not sure what the rating for this should be. It looks like Chrome rated it Security_Severity-Medium.

Comment 1

[Andrew McCreight [:mccr8]]

Nika said she might have time to implement the packed table approach.

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

They're dynamically generating them per-content-process after any sort of forkserver behavior, I assume. Otherwise I would think the content processes would share stringd at the same address and that just adds the step "Find the location of the strings in memory" to the attack, as an attacker reading process memory is within the threat-model post-Spectre.

This isn't really pixel stealing, but that tag has kind of become a catchall for timing attacks.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1793676 - Dynamically generate DOM code names for some continuous runs of codes, r=mccr8!

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Dynamically generate DOM code names for some continuous runs of codes, r=mccr8
https://hg.mozilla.org/integration/autoland/rev/ede1bcf6f11c0f75e450e4a7516b7aae8091817b
https://hg.mozilla.org/mozilla-central/rev/ede1bcf6f11c

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR102 approval when you get a chance. It grafts cleanly.

Comment 6

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 9298651 [details]
Bug 1793676 - Dynamically generate DOM code names for some continuous runs of codes, r=mccr8!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Easy uplift for potential sec bug fixed by chromium
• User impact if declined: potential side-channel for keystrokes
• Fix Landed on Version: 107
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple change which grafts cleanly

Comment 7

[Donal Meehan [:dmeehan]]

Comment on attachment 9298651 [details]
Bug 1793676 - Dynamically generate DOM code names for some continuous runs of codes, r=mccr8!

Approved for 102.5esr.

Comment 8

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/db9a92d5466c

Comment 9

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: advisory.txt