Restrict DeviceMotion to the active document




8 years ago
5 months ago


(Reporter: dougt, Assigned: dougt)


Dependency tree / graph
Bug Flags:
sec-review +

Firefox Tracking Flags

(firefox7+ fixed, firefox8+ fixed, firefox9+ fixed, status1.9.2 wontfix)


(Whiteboard: [sg:moderate][qa-][secr:dchan])


(1 attachment, 1 obsolete attachment)

derf sent me this from

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.
Assignee: nobody → doug.turner
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.
Posted patch sorta what I want... (obsolete) — Splinter Review
smaug, this is sort of what I want to do, but this prevents all device motion in Fennec.  Is there a better way?
Do you know why that prevents all the events in Fennec?
Also, you'd probably want to check if any of the parent windows (in docshell tree) is active.
Whiteboard: [sg:high]
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".
Posted patch patch v.1Splinter Review
IsBackground needs to be called on the outer window.  IsActive is only for the -moz-window-inactive pseudoclass
Attachment #555337 - Attachment is obsolete: true
Attachment #557256 - Flags: review?(Olli.Pettay)
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?
Attachment #557256 - Flags: review?(Olli.Pettay) → review+
Comment on attachment 557256 [details] [diff] [review]
patch v.1

yes.  works well on my test pages.
Attachment #557256 - Flags: approval-mozilla-beta?
Attachment #557256 - Flags: approval-mozilla-aurora? (check-in by edmorley)
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
Attachment #557256 - Flags: approval-mozilla-beta?
Attachment #557256 - Flags: approval-mozilla-beta+
Attachment #557256 - Flags: approval-mozilla-aurora?
Attachment #557256 - Flags: approval-mozilla-aurora+
Blocks: 686401
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
blocking1.9.2: --- → ?
status1.9.2: --- → ?
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.
blocking1.9.2: ? → ---
qa- as no QA fix verification needed
Whiteboard: [sg:high] → [sg:high][qa-]
Whiteboard: [sg:high][qa-] → [sg:moderate][qa-]
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?
Whiteboard: [sg:moderate][qa-] → [sg:moderate][qa-][secr: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.
Group: core-security
Whiteboard: [sg:moderate][qa-][secr:imelven] → [sg:moderate][qa-]
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.
Whiteboard: [sg:moderate][qa-] → [sg:moderate][qa-][secr:dchan]
I wrote a small webpage that added an eventListener to deviceorientation which incremented a counter. 

- 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.
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?
dchan - no.  fennec is busted.  See bug 718364.
(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 ?
the security review was completed a while ago. See bug 739729 for the background sensor issue
Flags: sec-review+
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.