Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 8 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Security
Team-Security-UX

Blocking:
issue 598674



Sign in to add a comment
Risks in current privacy/security policies of accessing to the mobile orientation and motion sensors via JavaScript codes
Reported by maryam.m...@gmail.com, Aug 21 2015 Back to list
Steps to reproduce the problem:
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 implementations of Chrome for both Android and iOS platforms in regards to accessing to 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 Chrome 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

What is the expected behavior?

What went wrong?
User's sensitive information will be compromised. 

Did this work before? N/A 

Chrome version: 44.0.2403.133  Channel: n/a
OS Version: 5.1.1
Flash Version: NA
 
Labels: Security_Impact-Stable Security_Severity-Low
Can you provide a site that demonstrates this data leak?
We are not aware of any website which performs this attack. We have implemented our own JavaScript code and trained a system to identify user's sensitive information such as PINs. A more detailed version of our work is available from here:
http://homepages.cs.ncl.ac.uk/m.mehrnezhad/


Cc: joh...@chromium.org f...@chromium.org palmer@chromium.org
Labels: Cr-Security-UX Cr-Security
A similar attack was discussed in detail on  https://crbug.com/421691 .  The conclusion there (#50 by palmer) was "the risk is acceptable as long as the web origin taking the accelerometer readings is in the main frame, in the foreground."

palmer -- Do you think that applies here?

The unpublished paper [1] uses Chrome's 60Hz sampling, and cites a 70% accuracy rate at detecting PIN digits.  This presumes the user is tapping a number key pad while the attacker's site, or iframe, is in the foreground.

[1] http://homepages.cs.ncl.ac.uk/m.mehrnezhad/TouchSignatures.pdf
Comment 4 by f...@chromium.org, Aug 21 2015
It sounds like a good reason to restrict it from iframes.

However I am not too worried about the parent frame case, because why would you be typing your device PIN into a website anyway?
Answer to comment #3: Yes it is a similar attack. 
Also as we observed and reported it in our unpublished paper, Chrome has different behaviors on Android and iOS. It provides access to the inactive tab in iOS too. Our attack scenario is easily applicable to this case too. 

Answer to comment #4: I do not exactly understand your question. I assume you mean users are more likely to deal with a website which requires them passwords rather than PINs. If that is your concern, we approve that. At the moment, we are working on the full keyboard recognition. 
Project Member Comment 7 by clusterf...@chromium.org, Aug 25 2015
Labels: Untriaged-1
Comment 8 by f...@chromium.org, Aug 27 2015
Re #6:

What I mean is that it isn't a risk for a foreground parent frame to be able to tell what you're typing (since it can do so anyway). If we ensure that the API requires both foreground status and parent frame, I think this problem should be resolved?
Re #8
At the moment there exist two different vulnerabilities in Chrome. First, having access to the mentioned sensor data by an inactive tab in the implementation of Chrome for iOS. Second, having access to the sensor data via iframrs which their origin is not the active (foreground) tab, on Android and iOS. In this case, for example an advert with the malicious code, does not have access to what you type directly, but it has access to the side channel sensor data and will threaten user's privacy/security.
Project Member Comment 10 by clusterf...@chromium.org, Aug 28 2015
Labels: -Untriaged-1 Untriaged-2
Project Member Comment 11 by clusterf...@chromium.org, Sep 1 2015
Labels: -Untriaged-2 Untriaged-3
Owner: f...@chromium.org
Status: Assigned
Over to felt in order to make a policy decision on this one.
Comment 13 Deleted
May I ask you please to update me if any decision/implementation has been made/suggested on this issue?
Comment 15 by f...@chromium.org, Dec 3 2015
Cc: timvolod...@chromium.org
Blocking: 598674
Cc: rbyers@chromium.org
Cc: ojan@chromium.org
Quick update: we're still discussing the options here.  It's tempting to just copy mobile safari (issue 598674) but we're concerned about limiting valuable scenarios.  Eg. embedded spherical videos, embedded maps using orientation data, etc. 
Thanks for the update Rick. We believe that the concern is valid too. 
Some summaries from an internal discussion thread:
 - We don't want to rely on user prompts, we don't think users will generally understand the implications
 - We may be willing to allow parent frames to opt-in to delegating sensor access to iframes (they can do this if the really want to already by postmessaging the data), but there is still some security risk there
 - We're particularly concerned about preventing interesting future use cases.  We suspect we could copy Safari's behavior without breaking too much existing content, but preventing new forms of content (like spherical video) is a serious risk.
Oh and we'd love to know if there's a safe rate we could throttle down to that might still be useful (eg. is 5hz still at all exploitable, what about 10hz)?

Or perhaps we could introduce some entropy / reduced spacial precision into the data which wouldn't seriously affect common use cases but would still mitigate the attack.
Hi, As I discussed it earlier, we also think that relying on user prompts is not a usable approach. We are currently conducting experiments on this, and will share the results with the community in the near future.  
A bunch of history (this has been actively discussed since 2011):
https://github.com/w3c/deviceorientation/issues/13
https://bugzilla.mozilla.org/show_bug.cgi?id=686401
http://w3c.github.io/deviceorientation/spec-source-orientation.html#security-and-privacy

FWIW I think we should hold out changing anything here until we have either:
1) some indication this is actually being attacked (pinpad entry on the web for sensitive information is quite rare)
2) indication that this attack can also be used to detect keystrokes on a full on-screen keyboard (in which case passwords could be at risk), or
3) A mitigation that doesn't completely break legitimate use cases like embedded spherical video (eg. introduction of entropy, reduce sampling rate, etc).
Given that this attack has been discussed in the community for awhile, I think we should open this bug up (as the mozilla bug was several years ago: (https://bugzilla.mozilla.org/show_bug.cgi?id=686401).  Any objections to removing the restriction?

My understanding is that both Safari and Firefox now block the cross-origin situation (crbug.com/598674). There is a more recent mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1197901
which implements the fix in Firefox 46.

Comment 27 by ojan@chromium.org, Apr 11 2016
rbyers, what's concerning about opt-in to delegate cross-origin iframe access?
Comment 28 by kenrb@chromium.org, Apr 11 2016
Labels: -Untriaged-3 -Restrict-View-SecurityTeam
I agree with rbyers... bug is now public.
IMHO opt-in is a pretty poor tradeoff:

1) It doesn't address a lot of the scenarios.  Eg. say Youtube wants to add spherical video support, they can't change all the existing iframe code out there (though they can suggest using it for new embed).

2) If the risk of attack is real, then an opt-in to insecure mode may (in the long run) lead to users still being subject to most of the risk.  Eg. if a few ads wants to show a perspective effect on device motion (especially if they're willing to pay slightly more for such ads) then all ad networks will eventually opt-in by default, without really knowing if the code they're running could be stealing keystrokes.  Perhaps this is no worse than existing malvertising scenarios (which already have robust mitigations), but it's still a risk.

That said, if there's new reason to believe the risk here is substantial, an opt-in (at least while we try to figure out the right long-term strategy) seems like a reasonably pragmatic step to me.
Labels: Hotlist-Input-Dev
Components: -Security>UX Internals>Permissions>Model
Components: -Security>UX Internals>Permissions>Model
Weird, how did the SecurityTeam view restriction get added back on? I don't see the label but nonetheless it's view restricted.
Labels: allpublic
Comment 35 by f...@chromium.org, Today (14 hours ago)
Owner: est...@chromium.org
Sign in to add a comment