681562 - Restrict DeviceMotion to the active document

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Doug Turner (:dougt)]

derf sent me this from https://db.usenix.org/events/hotsec11/tech/techAbstracts.html#Cai

TouchLogger: Inferring Keystrokes on Touch Screen from Smartphone Motion
Back to Program
Attacks that use side channels, such as sound and electromagnetic emanation, to infer keystrokes on physical keyboards are ineffective on smartphones without physical keyboards. We describe a new side channel, motion, on touch screen smartphones with only soft keyboards. Since typing on different locations on the screen causes different vibrations, motion data can be used to infer the keys being typed. To demonstrate this attack, we developed TouchLogger, an Android application that extracts features from device orientation data to infer keystrokes. TouchLogger correctly inferred more than 70% of the keys typed on a number-only soft keyboard on a smartphone. We hope to raise the awareness of motion as a significant side channel that may leak confidential data.


In a nutshell, we should prevent device motion from going to documents that are not active.

Comment 1

[Doug Turner (:dougt)]

I think what we want to do is just not send device motion events to any document that is in a window that is in the background or if that window is not active.

Comment 2

[Doug Turner (:dougt)]

Attachment: sorta what I want...

smaug, this is sort of what I want to do, but this prevents all device motion in Fennec.  Is there a better way?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Do you know why that prevents all the events in Fennec?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Also, you'd probably want to check if any of the parent windows (in docshell tree) is active.

Comment 5

[Daniel Veditz [:dveditz]]

when you say "documents that are not active" do you mean "top-level documents", or in a page with multiple iframes would you only send device motion to the frame that's focused?  The latter seems like it would break things. By active "document" I hope you mean "tab".

Comment 6

[Doug Turner (:dougt)]

Attachment: patch v.1

IsBackground needs to be called on the outer window.  IsActive is only for the -moz-window-inactive pseudoclass

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 557256 [details] [diff] [review]
patch v.1

I think this should be ok.
When a window is taken out from background, these events should
fire often enough so that right acceleration/orientation data
is updated to the page. Right?

Comment 8

[Doug Turner (:dougt)]

Comment on attachment 557256 [details] [diff] [review]
patch v.1

yes.  works well on my test pages.

Comment 9

[Doug Turner (:dougt)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/9fa4dee3e947

Comment 10

[Daniel Veditz [:dveditz]]

http://hg.mozilla.org/mozilla-central/rev/9fa4dee3e947 (check-in by edmorley)

Comment 11

[Doug Turner (:dougt)]

http://hg.mozilla.org/releases/mozilla-aurora/rev/95f04aa2a1c4
http://hg.mozilla.org/releases/mozilla-beta/rev/29bcbda58499

Comment 12

[Daniel Veditz [:dveditz]]

Do we need this fixed in 1.9.2? We don't support mobile there and I'm not sure we had Motion events, just Orientation events. Maybe they'd be enough to pull off this attack by themselves? Machines solidly on a desktop may not be as vulnerable.

Either way we'd need a new patch because the DeviceMotion files don't exist on the old branch (equivalent place looks like http://mxr.mozilla.org/mozilla1.9.2/source/widget/src/xpwidgets/nsAccelerometer.cpp#251).

Comment 13

[Daniel Veditz [:dveditz]]

This does not appear to be a currently practical attack against 3.6.x desktop Firefox users (or any users with a full keyboard) and likely won't be for the next couple of months of 3.6.x's remaining support lifetime. Won't backport the patch unless something comes up the changes the risk profile.

Comment 14

[u279076]

qa- as no QA fix verification needed

Comment 15

[Daniel Veditz [:dveditz]]

The heart of the patch is

+    if (!pwindow || pwindow->GetOuterWindow()->IsBackground())
+      continue;


Will the foreground tab be considered IsBackground() when another app has focus? Or could the active Firefox tab quietly listen in on what you type into other apps?

Comment 16

[Ian Melven :imelven]

i looked at the implementation of IsBackground() and it basically checks
whether the associated docshell is active. If the docshell isn't active when Firefox isn't the active application, this should be fine. Will follow up with Doug to make sure this is the case.

Comment 17

[Ian Melven :imelven]

Putting sec-review-needed back on here. We never got an answer as to whether the code behaves as we would like. I suggest someone give this a test to verify it's working as intended.

Comment 18

[David Chan [:dchan]]

I wrote a small webpage that added an eventListener to deviceorientation which incremented a counter. 

Scenarios
- Fennec in foreground, test tab is active
-- counter IS incremented
- Fennec in foreground, test tab is inactive e.g. another tab has focus
-- counter ISN'T incremented
- Fennec in background, test tab is active
-- counter IS incremented
- Fennec in background, test tab is inactive
-- counter ISN'T incremented

where background is a result of hitting the HOME button / changing apps so that Fennec is no longer in front

The third case doesn't seem correct to me. I would have thought that the page stops receiving events if Fennec is in the background.

Comment 19

[David Chan [:dchan]]

Can someone on the mobile team comment on whether the desired behavior is for Fennec to receive DeviceMotion events when it isn't in the foreground?

Comment 20

[Doug Turner (:dougt)]

dchan - no.  fennec is busted.  See bug 718364.

Comment 21

[Ian Melven :imelven]

(In reply to Doug Turner (:dougt) from comment #20)
> dchan - no.  fennec is busted.  See bug 718364.

sounds like this bug should be reopened then ?

Comment 22

[David Chan [:dchan]]

the security review was completed a while ago. See bug 739729 for the background sensor issue