Closed Bug 1616661 (CVE-2020-6812) Opened 8 months ago Closed 8 months ago

AirPods labels with personally identifiable information should not be exposed to the web

Categories

(Core :: WebRTC: Audio/Video, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla75
Tracking Status
firefox-esr68 74+ verified
firefox73 --- wontfix
firefox74 + verified
firefox75 + verified

People

(Reporter: jib, Assigned: jib)

Details

(Keywords: csectype-disclosure, sec-moderate, Whiteboard: [post-critsmash-triage][adv-main74+][adv-esr68.6+])

Attachments

(4 files)

AirPods seem to become named after their user by default e.g. "Jane Doe’s AirPods" the first time they're connected. Users can change this, if they know how. Most probably don't.

Firefox exposes this to web sites with camera or microphone permission.

This seems like an unintended privacy violation, since nowhere is it apparent to users that device labels are shared with web sites.

Assignee: nobody → jib
Group: media-core-security
Priority: -- → P2

STRs:

  1. (Make sure AirPods are connected to your laptop and) open https://jsfiddle.net/jib1/LbtxeLvw/
  2. Click Start Camera! button and hit "Allow" in the permission prompt (you don't have to choose AirPods here).
  3. Click Enumerate Devices! button.

Actual result:

...
audioinput: Jan-Ivar Bruaroey’s AirPods
...

Expected result: Don't share my full name with web page.

Additionally: if you chose the airpods, you'll see the following as well from track.label:

Microphone (live): Jan-Ivar Bruaroey’s AirPods
Group: core-security

I thought we exposed a generic device ID for everything? Preferably device IDs that change over time. The information is a fingerprinting problem even before we start leaking personal names on apple devices here!

This issue is about label (2), not deviceId. Labels get exposed to sites with cam/mic permission to let them implement in-content device selection. I've been championing an alternative to this, which I'll be speaking more about next week, so I'm happy to take input.

(In reply to Daniel Veditz [:dveditz] from comment #3)

I thought we exposed a generic device ID for everything? Preferably device IDs that change over time.
The information is a fingerprinting problem even before we start leaking personal names on apple devices here!

deviceIds are unique to the origin. There's a long discussion on public-webrtc about whether deviceId poses any fingerprinting risk above local storage except when mis-partitioned with local storage (bug 1589685).

https://browserleaks.com/webrtc

We have bug 1528042 about reigning in deviceId without permission for the sake of appearances (sites without permission see them rotate on process shutdown—would have been more frequently with bug 1223773 but I didn't get consensus for that). They're cleared with cookies. We could do a better job of making them less invisible. But let's keep this issue about labels.

[Tracking Requested - why for this release]: Disclosure of OS username. Might be good to land this mitigation sooner rather than later?

Jan-Ivar, are you going to request an uplift to beta and esr or can it ride the 75 train?

Flags: needinfo?(jib)

Comment on attachment 9127949 [details]
Bug 1616661 - Show raw device name to users in the gum prompt.

Beta/Release Uplift Approval Request

  • User impact if declined: Potential disclosure of OS username to web sites with camera or mic permission, if AirPods are connected (e.g. "Jane Doe’s AirPods").
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comment 2.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple string filter applied to JS-exposed string
  • String changes made/needed:

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Disclosure of OS username. Not limited to Macs.
  • User impact if declined: See above.
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): See above
  • String or UUID changes made by this patch:
Flags: needinfo?(jib)
Attachment #9127949 - Flags: approval-mozilla-esr68?
Attachment #9127949 - Flags: approval-mozilla-beta?
Attachment #9127677 - Flags: approval-mozilla-beta? approval-mozilla-esr68?

Comment on attachment 9127677 [details]
Bug 1616661 - Special-case AirPods in device enumeration.

approved for 74.0b9 and 68.6esr

Attachment #9127677 - Flags: approval-mozilla-esr68?
Attachment #9127677 - Flags: approval-mozilla-esr68+
Attachment #9127677 - Flags: approval-mozilla-beta?
Attachment #9127677 - Flags: approval-mozilla-beta+
Attachment #9127949 - Flags: approval-mozilla-esr68?
Attachment #9127949 - Flags: approval-mozilla-esr68+
Attachment #9127949 - Flags: approval-mozilla-beta?
Attachment #9127949 - Flags: approval-mozilla-beta+

Jan-Ivar, we don't have AirPods that we could use in order to verify this bug. Is there another type of device or another way we could verify this bug?

Flags: needinfo?(jib)

The fix is aimed at AirPods. But we only look at the name of the device, so if you have a (e.g. bluetooth) device that lets you configure its name, it should let you test it:

  • Rename device to e.g. "Jane Doe’s AirPods" and verify it shows as such in the Firefox prompt, but only as "AirPods" in JS output per comment 2.
  • Any other name that does not include "AirPods" should remain unaffected.
Flags: needinfo?(jib)

Odd it doesn't compile there. AFAICT const RefPtr<MediaEngineWebRTCAudioCaptureSource>& and const RefPtr<MediaDevice>& are unrelated types. A compiler bug perhaps?

1:27.95 /Users/Jan/moz/mozilla-central/dom/media/webrtc/MediaEngineWebRTC.cpp:265:29: note: in instantiation of function template specialization 'mozilla::MakeRefPtr<mozilla::MediaDevice, RefPtr<mozilla::MediaEngineWebRTCAudioCaptureSource> &, nsTString<char16_t>, NS_ConvertUTF8toUTF16, nsTString<char16_t>, const nsTLiteralString<char16_t> &>' requested here
1:27.95 aDevices->AppendElement(MakeRefPtr<MediaDevice>(
1:27.95 ^
1:27.95 /Users/Jan/moz/mozilla-central/dom/media/MediaManager.h:69:3: note: candidate constructor
1:27.95 MediaDevice(const RefPtr<MediaEngineSource>& aSource, const nsString& aName,
1:27.95 ^
1:27.95 /Users/Jan/moz/mozilla-central/dom/media/MediaManager.h:80:3: note: candidate constructor
1:27.95 MediaDevice(const RefPtr<MediaDevice>& aOther, const nsString& aID,
1:27.95 ^

I'm attaching an esr-specific workaround that wfm.

Flags: needinfo?(jib)
Flags: qe-verify+
Whiteboard: [post-critsmash-triage]

I have reproduced this behavior on Mac OS 10.14.6 with Nightly v75.0a1 from 2020-02-20 using A Platronics headset to which I changed the name to "John Doe's AirPods". The entire name gets displayed in the JS output (Enumerate devices action). I have verified the fix in Mac OS 10.14.6 with Nightly v75.0a1 from 2020-03-03, Beta v74.0b9 and ESR v68.6esr (candidate). Unfortunately, it cannot be verified on Windows and Ubuntu OSes with non-AirPods device because the device's name cannot be changed to "SOME Name's AirPods" or any other for that matter.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main74+][adv-esr68.6+]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.