On 28.04.2017 05:56, Ehsan Akhgari wrote: > On 04/27/2017 08:09 AM, Frederik Braun wrote: >> On 27.04.2017 13:56, smaug wrote: >>> On 04/25/2017 04:38 PM, Ehsan Akhgari wrote: >>>> On 04/24/2017 06:04 PM, Martin Thomson wrote: >>>>> I think that 60Hz is too high a rate for this. >>>>> >>>>> I suggest that we restrict this to top-level, foreground, and secure >>>>> contexts. Note that foreground is a necessary precondition for the >>>>> attack, so that restriction doesn't really help here. Critically, >>>>> rate limit access much more than the 60Hz recommended for the >>>>> accelerometer. 5Hz might be sufficient here, maybe even lower. >>>> How does restricting this to secure contexts help? >>> This is a good point to remember in this kinds of attacks. So often has >>> use of secure context suggested as the way to >>> fix issues, when it often doesn't really help at all with the core >>> issue. >>> >>> And the initial email did have >>> "Unshipping for non-secure context and making it HTTPS-only wouldn't >>> address the attack." >>> >> While it does not address the attack, it should be limited to secure >> context, if we keep the API. It's actually in the spec. > Why is that an advantage? Any attacker can use a secure context. The > word "secure" here relates to the security of the transport layer, but > if the origin itself is untrusted (which it is) exposing an unsafe > functionality to a "secure" context is just as unsafe. > > (And on the practical side of things, any attacker can use a free or > paid CA service to deliver their attack code through a secure channel.) >
Yes, yes and yes. This is not about the attack at all. This is about powerful features using secure contexts. >> >>> >>> (Also, secure context itself is in its current design rather broken, >>> IMO, yet hinting in its name that it is somehow secure. >>> BroadcastChannel or localStorage etc are easy ways to transfer data >>> from secure context to non-secure. ) >>> >>> >>> If I understand correctly the attacks being discussed in the article >>> referenced here are stealing >>>> cross origin data and user's history. These aren't things that we can >>>> expose to secure contexts any more than we can expose to insecure >>>> contexts. >>>>> Since the amount of information that can be extracted is a function of >>>>> the number of times the API is called and the accuracy of the reading, >>>>> we should consider also reducing the accuracy of the reading. The >>>>> attack reduced its information extraction to 1 bit per reading, but >>>>> you can't assume that this is the actual limit. Fuzzing is much >>>>> harder than it seems if your intent is to deal with an attack. I can >>>>> walk through some strategies if someone is interested in doing this. >>>>> >>>>> That all assumes that you aren't willing to add a dialog for this, >>>>> which seems like the right answer. That said, if the mitigation >>>>> strategies - rate limiting in particular - can't be implemented in a >>>>> reasonable time-frame, I would consider preffing this off (though the >>>>> pref name suggests that there would be collateral). >>>> It seems hard to explain the risks of granting this permission to a >>>> site to a user correctly. :-/ A permission prompt that doesn't allow >>>> us do that >>>> isn't very useful. Also given that the API is an event handler, it >>>> doesn't really lend itself to a permission prompt anyway. >>>> >>>> But also given the event handler nature of the API, not dispatching >>>> the event makes it very unlikely to break pages, unless if the page's >>>> functionality explicitly depends on the ambient light, I think, which >>>> works in our favor if we decide in that direction. I think I'm >>>> leaning in that >>>> way personally rather than coming up with a complicated heuristic here >>>> and potentially getting it wrong. >>>>> On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston <j...@mozilla.com> >>>>> wrote: >>>>>> As a follow up, it looks like the device motion events defined in the >>>>>> device sensors: >>>>>> http://searchfox.org/mozilla-central/source/dom/system/nsDeviceSensors.cp >>>>>> >>>>>> >>>>>> should also be restricting based on isSecureContext. >>>>>> >>>>>> The spec mentions "should take into consideration the following >>>>>> suggestions" >>>>>> : >>>>>> https://www.w3.org/TR/orientation-event/#security-and-privacy >>>>>> >>>>>> We don't do those measures from what I can see. >>>>>> >>>>>> Can we make the webIDL represent this requirement for requiring >>>>>> secure >>>>>> context instead? >>>>>> >>>>>> Thanks >>>>>> Jonathan >>>>>> >>>>>> On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston <j...@mozilla.com> >>>>>> wrote: >>>>>> >>>>>>> As mentioned a permission prompt isn't great. >>>>>>> >>>>>>> In it's current state it should probably be considered a "powerful >>>>>>> feature" that we can remove just for secure context. Granted this >>>>>>> doesn't >>>>>>> fix the exploit mentioned here though. >>>>>>> >>>>>>> Freddy highlighted that the spec itself suggests the Generic Sensor >>>>>>> API is >>>>>>> the security model which requires: https://www.w3.org/TR/generic- >>>>>>> sensor/#secure-context I can't see that as a restriction in our >>>>>>> codebase >>>>>>> though? >>>>>>> >>>>>>> This looks like a specification violation here. >>>>>>> >>>>>>> Thanks >>>>>>> Jonathan >>>>>>> >>>>>>> On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun <fbr...@mozilla.com> >>>>>>> wrote: >>>>>>> >>>>>>>> The Ambient Light spec defers its security and privacy >>>>>>>> considerations to >>>>>>>> the generic sensors specification, which states >>>>>>>> >>>>>>>>> all interfaces defined by this specification or extension >>>>>>>> specifications must only be available within a secure context. >>>>>>>> >>>>>>>> >>>>>>>> Would we require telemetry before we restricted this to secure >>>>>>>> contexts? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 24.04.2017 15:24, Frederik Braun wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> there is a relatively recent blog post [1] by Lukasz Olejnik and >>>>>>>>> Artur >>>>>>>>> Janc that explains how one can steal sensitive data using the >>>>>>>>> Ambient >>>>>>>>> Light Sensor API [2]. >>>>>>>>> >>>>>>>>> We ship API and its enabled by default [3,4] and it seems we >>>>>>>>> have no >>>>>>>>> telemetry for this feature. >>>>>>>>> >>>>>>>>> >>>>>>>>> Unshipping for non-secure context and making it HTTPS-only >>>>>>>>> wouldn't >>>>>>>>> address the attack. >>>>>>>>> >>>>>>>>> The API as implemented is using the 'devicelight' event on window. >>>>>>>>> I suppose one might also be able to implement a prompt for >>>>>>>>> this, but >>>>>>>>> that doesn't sound very appealing (prompt fatigue, etc., etc.). >>>>>>>>> >>>>>>>>> >>>>>>>>> What do people think we should do about this? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Freddy >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://blog.lukaszolejnik.com/stealing-sensitive-browser- >>>>>>>> data-with-the-w3c-ambient-light-sensor-api/ >>>>>>>>> [2] https://www.w3.org/TR/ambient-light/ >>>>>>>>> [3] It is behind the dom.sensors.enabled (sic!) flag. >>>>>>>>> [4] >>>>>>>>> http://searchfox.org/mozilla-central/source/dom/system/nsDev >>>>>>>> iceSensors.cpp >>>>>>>> _______________________________________________ >>>>>>>> dev-platform mailing list >>>>>>>> dev-platform@lists.mozilla.org >>>>>>>> https://lists.mozilla.org/listinfo/dev-platform >>>>>>>> >>>>>> _______________________________________________ >>>>>> dev-platform mailing list >>>>>> dev-platform@lists.mozilla.org >>>>>> https://lists.mozilla.org/listinfo/dev-platform >>>>> _______________________________________________ >>>>> dev-platform mailing list >>>>> dev-platform@lists.mozilla.org >>>>> https://lists.mozilla.org/listinfo/dev-platform >>> _______________________________________________ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
