1616661 - (CVE-2020-6812) AirPods labels with personally identifiable information should not be exposed to the web

Status: VERIFIED FIXED

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

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Bug 1616661 - Special-case AirPods in device enumeration.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 3

[Daniel Veditz [:dveditz]]

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!

Comment 4

[Daniel Veditz [:dveditz]]

https://browserleaks.com/webrtc

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Bug 1616661 - Show raw device name to users in the gum prompt.

Depends on D63387

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/bb9a59f0ce925493333414c836ba83b48808b546
https://hg.mozilla.org/integration/autoland/rev/ae8b63c2c7041e71cf1af419f06904f68556fb36
https://hg.mozilla.org/mozilla-central/rev/bb9a59f0ce92
https://hg.mozilla.org/mozilla-central/rev/ae8b63c2c704

Comment 9

[Pascal Chevrel:pascalc]

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

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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:

Comment 11

[Julien Cristau [:jcristau]]

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

approved for 74.0b9 and 68.6esr

Comment 12

[Brindusa Tot, Desktop QA]

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?

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/46c37c9fc23b
https://hg.mozilla.org/releases/mozilla-beta/rev/98a86f847c48

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/24241169e9d6
https://hg.mozilla.org/releases/mozilla-esr68/rev/7d86454fd261

Comment 15

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Backed out from ESR68 due to build bustage.
https://hg.mozilla.org/releases/mozilla-esr68/rev/be31d6a4cc2a

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=290811683&repo=mozilla-esr68&lineNumber=19343

Comment 17

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: esr_workaround.patch

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.

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/2ae01e2ee32f
https://hg.mozilla.org/releases/mozilla-esr68/rev/793cfb8b4a7e
https://hg.mozilla.org/releases/mozilla-esr68/rev/08f21f9c9959

Comment 19

[Daniel Bodea [:danibodea]]

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.

Comment 20

[Tom Ritter [:tjr]]

Attachment: advisory.txt