Opened 2 years ago

Closed 2 years ago

#17009 closed defect (fixed)

Shift and Alt keys leak physical Keyboard layout

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting, TorBrowserTeam201512R
Cc: gk, isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In our patch for #15646, we spoofed the KeyboardEvent.code and KeyboardEvent.keyCode, so that a KeyboardEvent for a given character always reports the same physical key regardless of the true keyboard layout. However, it is still possible to deduce keyboard layout by looking at key combinations. For example, on an AZERTY keyboard such as those used in France, the digit keys (1,2,3...0) require that the user press the Shift key. Even though we spoof the keyboardEvent.shiftKey flag to false for digit keys, it's easy to see when Shift is depressed by monitoring the keyup and keydown events that the Shift key generates on its own. So that gives a method of distinguished QWERTY and AZERTY keyboards. There are similar issues with Alt and Shift+Alt generating special characters.

So I would suggest suppressing all keyup and keydown events for the Shift and Alt keys.

Child Tickets

Change History (36)

comment:1 Changed 2 years ago by arthuredelstein

Status: newneeds_review
Last edited 2 years ago by arthuredelstein (previous) (diff)

comment:2 Changed 2 years ago by gk

Cc: gk added

comment:3 Changed 2 years ago by cypherpunks

This patch seems insufficient. getModifierState could be used polling the keyboard.

There are a lot more modifiers that can leak information:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/getModifierState

comment:4 Changed 2 years ago by isis

Cc: isis added

comment:5 in reply to:  3 Changed 2 years ago by arthuredelstein

Replying to cypherpunks:

This patch seems insufficient. getModifierState could be used polling the keyboard.

There are a lot more modifiers that can leak information:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/getModifierState

You're right -- thanks for catching this. Here's a new version of the patch that ensures that KeyboardEvent.getModifierState("Alt") === KeyboardEvent.altKey and KeyboardEvent.getModifierState("Shift") === KeyboardEvent.shiftKey.

https://github.com/arthuredelstein/tor-browser/commit/17009+1

comment:6 Changed 2 years ago by arthuredelstein

The patch I've just posted stands on its own, but I'm also considering whether we need to suppress events for other special keys. Isis pointed out that a tiling window manager requires frequent use of the OSLeft key, so maybe that's a good one to hide.

comment:7 Changed 2 years ago by cypherpunks

You should also include "AltGraph" (language/keyboard specific):
https://en.wikipedia.org/wiki/AltGr_key

as well as "Meta" and "OS" (OS specific).

comment:8 in reply to:  7 ; Changed 2 years ago by arthuredelstein

Keywords: TorBrowserTeam201509 added; TorBrowserTeam201509R removed
Status: needs_reviewneeds_revision

Replying to cypherpunks:

You should also include "AltGraph" (language/keyboard specific):
https://en.wikipedia.org/wiki/AltGr_key

Good point -- I will suppress events like { key: "AltGraph" } on the next iteration in this ticket.

as well as "Meta" and "OS" (OS specific).

I'm not sure about these. Suppose the user presses a key combination like Meta+A (Select-All on OS X). Then there will first be a { key: "Meta" } keydown event, followed by an { key: "A", metaKey: true } keydown event (followed by more events with redundant information). This reveals the platform (OS X), but not much else as far as I can tell. Or am I missing something?

(Here's a page for testing: https://arthuredelstein.github.io/tordemos/keyboard.html)

comment:9 Changed 2 years ago by arthuredelstein

Here's a new version of the patch with AltGraph events suppressed:
https://github.com/arthuredelstein/tor-browser/commit/17009+2

comment:10 in reply to:  8 ; Changed 2 years ago by cypherpunks

Replying to arthuredelstein:

This reveals the platform (OS X), but not much else as far as I can tell. Or am I missing something?

Yes, it reveals the platform. Can the platform already be determined by other means?

comment:11 in reply to:  10 Changed 2 years ago by arthuredelstein

Replying to cypherpunks:

Replying to arthuredelstein:

This reveals the platform (OS X), but not much else as far as I can tell. Or am I missing something?

Yes, it reveals the platform. Can the platform already be determined by other means?

Yes, unfortunately there are lots of ways for an adversary to determine the platform. For example differences in the font set, Intl formatting, graphics rendering, Math functions. For now we have decided not to attempt to conceal Mac vs Windows vs Linux, because it's too difficult and also costly to usability.

comment:12 Changed 2 years ago by elypter

can the type of mouse be fingerprinted if a user presses a special mouse button?

comment:13 in reply to:  12 Changed 2 years ago by arthuredelstein

Replying to elypter:

can the type of mouse be fingerprinted if a user presses a special mouse button?

Good question. I have opened a ticket: #17023

comment:14 Changed 2 years ago by arthuredelstein

Keywords: TorBrowserTeam201509R added; TorBrowserTeam201509 removed
Status: needs_revisionneeds_review

(Proposing patch in comment:9 for review.)

comment:15 in reply to:  14 Changed 2 years ago by arthuredelstein

Keywords: TorBrowserTeam201509 added; TorBrowserTeam201509R removed
Status: needs_reviewneeds_revision

Replying to arthuredelstein:

(Proposing patch in comment:9 for review.)

(Postponing this patch until we can tie it to a pref for suppressing the ALT and SHIFT events.)

comment:16 Changed 2 years ago by arthuredelstein

I have split the changes here into three patches:

  1. Fixup our KeyboardEvent patch to ensure that the modifierState property matches the altKey and shiftKey properties.
  2. Create a mechanism for suppressing Shift and Alt keydown/keyup events (separate events from Shift+Q, etc.)
  3. Enable the pref in patch (2).

Here's a branch with all three patches:
https://github.com/arthuredelstein/tor-browser/commits/17009+3

comment:17 Changed 2 years ago by arthuredelstein

Keywords: TorBrowserTeam201509R added; TorBrowserTeam201509 removed
Status: needs_revisionneeds_review

comment:18 Changed 2 years ago by gk

Moving needs_review tickets to October 2015.

comment:19 Changed 2 years ago by gk

Keywords: TorBrowserTeam201510R added; TorBrowserTeam201509R removed

Batch modification for realz now.

comment:20 Changed 2 years ago by gk

Keywords: TorBrowserTeam201511R added; TorBrowserTeam201510R removed

comment:21 Changed 2 years ago by gk

Severity: Normal
Status: needs_reviewneeds_revision

Okay, I played with it a bit on my Linux box. If I happen to have focus on the content page then my interaction with the menu via keyboard are broken in a weird way. First, hitting the Alt-key alone is not activating the menu bar anymore (which some users might see as a feature). That might be okay for an alpha at least, I think (although not being able to hide the menu bar anymore by just pressing the Alt-key a second time might be more problematic). Where it gets weird is if I want to switch to a different item on the menu bar. Let's say I have the dropdown for the Edit item open (just pressed Alt+e) and want to switch with Alt+f to the File menu. This does not work. Rather, the find bar is popping up at the bottom of the window. Or let's say I have the File menu open and like to switch to the View menu. This does not work either. Rather, the print preview is popping up which is quite confusing. I think this part at least needs a revision.

Last edited 2 years ago by gk (previous) (diff)

comment:22 Changed 2 years ago by gk

But looking closer this is not so weird anymore: As Alt events are suppressed the shortcuts on the open menu are used if a key is pressed in addition: f in the edit menu results in opening the find bar and v in the file menu in openening the print preview.

comment:23 Changed 2 years ago by gk

I wonder if there is a way to distinguish between event listeners from content pages and those from chrome code (i have not checked the code). If so, then we could let these events get created in the first place but allow them only to bubble up to chrome listeners.

comment:24 Changed 2 years ago by gk

Oh, and another thing I forgot: this problem visible as well on about: pages although I guess it should be fine to have proper functioning keys on, say about:memory or about:tor etc.

comment:25 in reply to:  23 Changed 2 years ago by arthuredelstein

Replying to gk:

I wonder if there is a way to distinguish between event listeners from content pages and those from chrome code (i have not checked the code). If so, then we could let these events get created in the first place but allow them only to bubble up to chrome listeners.

It turns out that in vanilla Firefox, content-generated KeyboardEvents are shared with chrome. So the problem with this patch is that I was deleting events from content pages, so that chrome wasn't seeing them either. So I need to look into whether it is possible to just send the events to chrome and keep them from being visible to content.

Last edited 2 years ago by arthuredelstein (previous) (diff)

comment:26 Changed 2 years ago by gk

Keywords: TorBrowserTeam201511 added; TorBrowserTeam201511R removed

comment:27 Changed 2 years ago by mikeperry

Keywords: TorBrowserTeam201512 added; TorBrowserTeam201511 removed

comment:28 Changed 2 years ago by arthuredelstein

Status: needs_revisionneeds_review

Here's a revised version that allows Shift and Alt KeyboardEvents to be generated, but make those events invisible to content, dispatching them to chrome scripts only.

https://github.com/arthuredelstein/tor-browser/commits/17009+4

As before, there are three patches:

  1. 8a38085, Fixup our KeyboardEvent patch to ensure that the modifierState property matches the altKey and shiftKey properties.
  2. 9154cda, Create a mechanism for suppressing Shift and Alt keydown/keyup events in content (while not suppressing events like { key: Q, modifier: shift }, etc.)
  3. a52af8e, Enable the pref in patch (2).

comment:29 Changed 2 years ago by gk

Keywords: TorBrowserTeam201512R added; TorBrowserTeam201512 removed

comment:30 Changed 2 years ago by mcs

r=mcs with a few questions:
Does it make sense to use Preferences::AddBoolVarCache() for the privacy.suppressModifierKeyEvents pref?

Do we have any automated test for our keyboard event fingerprinting defenses? If not, we should file a ticket so we remember to add some.

Has this been tested on Linux and Windows? I tested on Mac OS using your https://arthuredelstein.github.io/tordemos/keyboard.html page but I could do more testing.

comment:31 in reply to:  30 Changed 2 years ago by arthuredelstein

Replying to mcs:

Does it make sense to use Preferences::AddBoolVarCache() for the privacy.suppressModifierKeyEvents pref?

Has this been tested on Linux and Windows? I tested on Mac OS using your https://arthuredelstein.github.io/tordemos/keyboard.html page but I could do more testing.

These are both good suggestions. I try them out tomorrow (Wednesday).

Do we have any automated test for our keyboard event fingerprinting defenses? If not, we should file a ticket so we remember to add some.

Filed: #17790

comment:32 Changed 2 years ago by gk

Another wish-item: could you rebase your patches against the latest tor-browser-38.4.0esr-5.5-1 branch?

comment:33 Changed 2 years ago by arthuredelstein

Here's a new version of the patch using AddBoolVarCache, and rebased to the latest tor-browser-38.4.0esr-5.5-1 branch. I tested on Mac as well, but I am still in the process of building Windows and Linux versions for testing.

There are three patches, as described in comment:28:

https://github.com/arthuredelstein/tor-browser/commits/17009+5

comment:34 Changed 2 years ago by mcs

r=mcs, r=brade
But we should probably wait for the results of Arthur's tests on Linux and Windows.

comment:35 Changed 2 years ago by arthuredelstein

I have now confirmed the patch is working on Mac, Linux and Windows. Here are the builds, if anyone else wants to try:

https://people.torproject.org/~arthuredelstein/downloads/17009-builds/

comment:36 Changed 2 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks good to me and applied to tor-browser-38.4.0esr-5.5-1 (62ad9e1b780579ad459823253bcb8b47fefdd414, b1e0a3252e5d556652d71d16dd501317196a5a66 and b1c9000a21e664f7978c8dd9f18f9d47663f49c8).

Note: See TracTickets for help on using tickets.