Shift and Alt keys leak physical Keyboard layout

In our patch for #15646 (moved), 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.

added TorBrowserTeam201512R component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-fingerprinting type::defect labels

Here's a proposed patch: https://github.com/arthuredelstein/tor-browser/commit/17009

Trac:
Status: new to needs_review

Trac:
Cc: N/A to gk

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

Trac:
Cc: gk to gk, isis

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

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.

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

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

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)

Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201509R deleted, TorBrowserTeam201509 added

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

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?

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.

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

Trac:
Username: elypter

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 (moved)

(Proposing patch in comment:9 for review.)

Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201509 deleted, TorBrowserTeam201509R added

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.)

Trac:
Keywords: TorBrowserTeam201509R deleted, TorBrowserTeam201509 added
Status: needs_review to needs_revision

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

Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201509 deleted, TorBrowserTeam201509R added

Moving needs_review tickets to October 2015.

Batch modification for realz now.

Trac:
Keywords: TorBrowserTeam201509R deleted, TorBrowserTeam201510R added

Trac:
Keywords: TorBrowserTeam201510R deleted, TorBrowserTeam201511R added

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.

Trac:
Severity: N/A to Normal
Status: needs_review to needs_revision
Sponsor: N/A to N/A

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.

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.

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.

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.

Trac:
Keywords: TorBrowserTeam201511R deleted, TorBrowserTeam201511 added

Trac:
Keywords: TorBrowserTeam201511 deleted, TorBrowserTeam201512 added

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).

Trac:
Status: needs_revision to needs_review

Trac:
Keywords: TorBrowserTeam201512 deleted, TorBrowserTeam201512R added

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.

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 (moved)

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

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

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

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/

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

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #17790 (moved)

mentioned in issue #27268 (moved)

moved to tpo/applications/tor-browser#17009 (closed)

mentioned in issue tpo/applications/tor-browser#17790 (closed)