1197901 - (CVE-2016-2813) Risks in the current implementation of Firefox on Android in accessing to the mobile orientation and motion sensors via JavaScript codes

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Maryam]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

Dear Sir/ Madam,
I am writing to you on behalf of a team of researchers in mobile security from Newcastle University, UK. Based on our recent work, we have identified vulnerabilities in the current implementation of Firefox for Android in regards to accessing to the mobile orientation and motion sensors via JavaScript codes. The results of our work show that it is possible to infer user’s touch actions such as click, scroll, and zoom, as well as his PINs based on the sensor streams accessible through different mobile browsers including yours. This feature seems to be implemented in Firefox according to the W3C device orientation event specification (http://www.w3.org/TR/orientation-event/) which needs to be revised too. 
A preliminary version of our work is already published here (http://dl.acm.org/citation.cfm?id=2714650). The detailed version of the paper including attacks on user’s PINs will be published soon. We would be very happy to provide you with more information in regards to this problem.
Regards,
Maryam Mehrnezhad



Actual results:

User privacy and security leak

Comment 1

[Daniel Veditz [:dveditz]]

We don't have access to your paper, please attach a copy to this bug or mail us at [e-mail]

Comment 2

[Maryam]

Attachment: TouchSignatures.pdf

Short version of the paper

Comment 3

[Maryam]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> We don't have access to your paper, please attach a copy to this bug or mail
> us at [e-mail]

Short version of the paper is attached to the bug now. You can find the detailed version of the paper from: http://homepages.cs.ncl.ac.uk/m.mehrnezhad/

Comment 4

[Andrew McCreight [:mccr8]]

Olli, do you know who might be able to look into this issue?

Comment 5

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

Hmm, didn't dougt work on orientation and motion sensors?

Maryam, do you by any chance have some code showing the issue?
Also, do you perhaps have links to bugs you have filed (I assume) on other browsers?


I wonder if we should either make deviceorientation/devicemotion use some permission model
(so that when an event listener is added, permission is asked), or limit those events to top level page, and nested browsing context from the same domain. I think I'd prefer the latter one.
Anne, any comments?

Comment 6

[Andrew McCreight [:mccr8]]

There's some code at the very end of the paper here:
http://homepages.cs.ncl.ac.uk/m.mehrnezhad/TouchSignatures.pdf

Comment 7

[Anne (:annevk)]

Your suggestion seems reasonable. I don't really know about the specific attacks, but I have heard about using orientation events to steal passwords a long time ago. What's new?

Comment 8

[Ehsan Toreini]

It is completely new attack via only JavaScript codes. Before, it is been done by installing native apps on mobile devices.

Comment 9

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

I'd say this is a dup of bug 686401, so nothing new.

Comment 10

[Daniel Veditz [:dveditz]]

Making the attack practical in javascript may be new (and very cool research), but as seen in bug 686401 the Firefox defenses we'd need to protect against the attack were predicted based on nascent research.

Comment 11

[Ehsan Toreini]

It is the same bug as 686401, however, our research proves it is indeed practical to perform such an attack.

Comment 12

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

Indeed, and it should be fixed consistently across all the browsers and also the spec needs to be fixed. Do you have links to bugs on other browser implementations? That might help with coordinating this work.

Comment 13

[Maryam]

We have reported the issue to all major browsers and also w3c. Some of them are discussing the bug inside private groups. None of them are public yet.

Comment 14

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

Maryam, could you still give the links to other browsers bugs. I know those are probably hidden by 
default, but I could then ask the developers of other browsers to give access to those bugs.

Comment 15

[Maryam]

It's issue 523320 in Chromium. For the rest browsers we are in contact with them via email.

Comment 16

[timvolodine]

there is some relevant chromium discussion here: crbug.com/421691

Comment 17

[Matt Wobensmith [:mwobensmith][:matt:]]

Marking sec-high for now until further investigation can be made.

Comment 18

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

MS and Blink folks seem to be ok with the approach from bug 686401.

Comment 19

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

Attachment: possible patch

This would limit events to foreground tabs in focused windows.

Comment 20

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

Attachment: v3

Comment 21

[Maryam]

I've been trying to follow the conversation, however I am not authorized to access bug 1211258. Is there any way for me to see this bug?

Comment 22

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

Comment on attachment 8669419 [details] [diff] [review]
v3

For FFOS we need bug 1211258.

DeviceSensorTestEvent is a bit silly, but we don't really have other ways to test this stuff.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8669419 [details] [diff] [review]
v3

>+    principal->Subsumes(topPrincipal, &subsumes);

Could we just add a one-arg form of Subsumes() on nsIPrincipal (presumably inline)?  It worries me that you're not considering rv....  you probably should.

r=me modulo that.

Comment 24

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

well, if subsumes (which is initialized to false) is set to true yet the method returns failure, I'd say that is rather horrible bug in ::Subsumes implementation.
But now I see we have the easier to use Subsumes() for C++.

Comment 25

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

Attachment: simpler subsumes

Comment 26

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

Comment on attachment 8670428 [details] [diff] [review]
simpler subsumes

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
It is obvious what the issue is about, but actually constructing an exploit... 
http://homepages.cs.ncl.ac.uk/m.mehrnezhad/TouchSignatures.pdf is public and bug 686401 has been open for years.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Commit message could be
-u "Olli Pettay <[e-mail]>" -m "Bug 1197901, ensure sensor events dispatching follows the becoming spec change, r=bz"

Which older supported branches are affected by this flaw?
All

If not all supported branches, which bug introduced the flaw?
(This is old stuff, known at least since bug 686401)

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
The patch seems to apply to older branches, expect the testing part of the patch

How likely is this patch to cause regressions; how much testing does it need?
this changes functionality a bit, so, not super safe.

Comment 27

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8670428 [details] [diff] [review]
simpler subsumes

Sec-approval+ for checkin to trunk. We should take this on Beta and Aurora too. Marking as won't fix for ESR38 since this is Fennec specific and we don't have an ESR for Fennec.

Comment 28

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

Looks like we have still some issue in FFOS
(I thought bug 1211258 would have been enough). Investigating.

Comment 29

[Sylvestre Ledru [:Sylvestre]]

Olli, are you planning to request the uplift to 42 & 43? Thanks

Comment 30

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

No. Need to sort out the FFOS issues first.
I should have asked sec approval a bit later.

Comment 31

[Sylvestre Ledru [:Sylvestre]]

OK. I am going to mark it wontfix for 42. Please let me know if the situation changes.

Comment 32

[Liz Henry (:lizzard) (relman/hg->git project)]

Any luck here Olli? We can still take a patch in beta. If you think it will still be wontfixed for 43, please let me know.

Comment 33

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

Attachment: up-to-date (for trunk)

Still debugging b2g issues.

Comment 34

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

Attachment: up-to-date (for trunk)

Comment 35

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Smaug: Just poking this bug as it's a sec-high and tracked for FF44, do we know the issue better and potentially a fix ready for uplift to Beta44? Please let me know.

Comment 36

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for 43, wontfixing. 
Marking affected and adding tracking for 45/46 since it looks like they're also affected

Comment 37

[Sylvestre Ledru [:Sylvestre]]

Untracking as we shipped several releases with it.
Please resubmit when we have a fix ready to land.

Comment 38

[Liz Henry (:lizzard) (relman/hg->git project)]

smaug - Would you like to take another look at checking this fix in without considering the b2g issues?  Seems like priorities may have shifted here so it would be worth finally fixing this sec-high bug.

Comment 39

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

Attachment: up-to-date (for trunk)

Comment 40

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

Attachment: up-to-date (aurora & beta)

Comment 41

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

Comment on attachment 8720426 [details] [diff] [review]
up-to-date (for trunk)

Trying again now

[Security approval request comment]
See comment 26

Comment 42

[Maryam]

Hi all, 
A quick update on W3C new draft, Thought it might be interesting for you:
https://github.com/w3c/deviceorientation/pull/25/files#diff-87104462239df473f9aa72c3bb6ad124R641

Comment 43

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

Comment on attachment 8720427 [details] [diff] [review]
up-to-date (aurora & beta)

Approval Request Comment
[Feature/regressing bug #]: We've had the old behavior for ages.
[User impact if declined]: See the comment 0
[Describe test coverage new/current, TreeHerder]: Added a test
[Risks and why]: non-same-origin iframes in pages can't use the feature anymore,
but it is a spec change (which doesn't mean the change is web compatible, unfortunately).
[String/UUID change made/needed]: NA

Comment 44

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/78d2fbf52588

Comment 45

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/78d2fbf52588

Comment 46

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8720427 [details] [diff] [review]
up-to-date (aurora & beta)

This is too late in the 45 cycle. This is the last week of the beta cycle.
Taking it in aurora.

Comment 47

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/163849e878fc

Comment 48

[Daniel Veditz [:dveditz]]

Still no ESR for Fennec

Comment 49

[Maryam]

Thanks everyone for taking action on our reported bug as announced here:
https://www.mozilla.org/en-US/security/advisories/mfsa2016-43/

For a detailed version of our work, the journal version of the paper is freely accessible from:
http://arxiv.org/abs/1602.04115

-Maryam