Closed Bug 1528335 (CVE-2019-11723) Opened 5 years ago Closed 5 years ago

`InstallTrigger` and `mozAddonManager` leaking cookies in private browsing mode


(Toolkit :: Add-ons Manager, defect, P1)




Tracking Status
firefox-esr60 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed


(Reporter: TheOne, Assigned: Gijs)


(Keywords: privacy, sec-low, Whiteboard: [fingerprinting][post-critsmash-triage][adv-main68+])


(4 files, 1 obsolete file)

In private browsing mode, websites that call InstallTrigger to trigger the install of a download leak cookies that were set outside of private browsing mode in the request to fetch the add-on file.

The same counts for AMO, that is using mozAddonManager: When installing an add-on from AMO in private browsing mode, the non-private browsing cookies from AMO are included in the request to fetch the file.

exemplary STR for AMO:

  1. Open AMO in non-private browsing mode
  2. Open the devtools and make note of the "sessionid" cookie for requests.
  3. Clear your cache (important!)
  4. Open AMO in private browsing mode.
  5. In the web console, execute:

navigator.mozAddonManager.createInstall({ url: "", hash: "sha256:b7aa57bd91943a2d3dd3621872e8700b2f59665db5c92fc54bca5049780cc91c" }).then((install) => { install.install(); })

(This is pretty much what clicking on the "Add to Firefox" button would do).

  1. In the network panel, inspect the request to get that file and check the cookies. The "sessionid" cookie should be identical to the one in (2).

Is this a regression? I can confirm beta is affected; have you tried release?

Flags: needinfo?(awagner)
Attached patch Tentative patch ideas (obsolete) — Splinter Review

I vaguely recall we tried to do something like this before, but we didn't go through with it. I suspect it's because we didn't serialize principals sent from JS at the time (we do now, bug 1515863 fixed in 66 and later), though I could be wrong. Anyway, this code seems to work for me (only tried with the example in comment #0, haven't tried InstallTrigger, haven't run any tests, etc.).

Dumb idea? Am I missing anything?

(Christoph, do these flags for the actual channel look approximately right?)

Attachment #9044524 - Flags: feedback?(kmaglione+bmo)
Attachment #9044524 - Flags: feedback?(dtownsend)
Attachment #9044524 - Flags: feedback?(ckerschb)
Comment on attachment 9044524 [details] [diff] [review]
Tentative patch ideas

Review of attachment 9044524 [details] [diff] [review]:

Yeah, the approach you take and the flags you send seem correct to me - go for it!
Attachment #9044524 - Flags: feedback?(ckerschb) → feedback+
Comment on attachment 9044524 [details] [diff] [review]
Tentative patch ideas

Not seeing any obvious problem, but I'm a bit outdated on this code, kmag is probably more up to date.
Attachment #9044524 - Flags: feedback?(dtownsend) → feedback+
Assignee: nobody → gijskruitbosch+bugs
Priority: -- → P1
Attachment #9044524 - Flags: feedback?(kmaglione+bmo) → feedback+

(In reply to :Gijs (he/him) from comment #1)

Is this a regression? I can confirm beta is affected; have you tried release?

I can reproduce this in 65.0.1.

Flags: needinfo?(awagner)

Not too worried about mozAddonManager since it's only available to our own sites, but this means InstallTrigger() could be used as a sneaky tracking mechanism. Would be noisy though since by default users will get a prompt that a site it trying an install before we send anything.

Whiteboard: [fingerprinting]

There's no way I'm getting to polishing this up, writing tests, getting review, and uplift to 66, in the next week or so. Too much other stuff. Marking wontfix for 66 given that, and the fact that this is sec-low.

Group: toolkit-core-security → firefox-core-security

I expect this has just always been broken...

Attachment #9044524 - Attachment is obsolete: true
Attached file Bug 1528335, r?aswan

Depends on D25774

Flags: needinfo?(gijskruitbosch+bugs)

Turns out AddonManager.getInstallForURL / XPIInstall.getInstallForURL is used a lot, and requiring principals there doesn't seem like a good fix... poking at this some more.

Andrew figured out the leaks \o/

bug 1541577

Landing this patchset with the test disabled on debug for now:

Flags: needinfo?(gijskruitbosch+bugs)

Hi Gijs, since 67 is affected, do you want to uplift this fix to Beta67? Thanks!

Flags: needinfo?(gijskruitbosch+bugs)

I'm not 100% sure about uplifting... Andrew, thoughts?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(aswan)

Its a tough call. I trust the patch and we have pretty thorough existing tests to catch other regressions it might cause. But the patch touches a decent amount of code and this is a sec-low which makes me lean toward "no".

Flags: needinfo?(aswan)

Alright, let's call it.

Flags: qe-verify+
Whiteboard: [fingerprinting] → [fingerprinting][post-critsmash-triage]

Could you please provide more details from where exactly I should get the "sessionid" from?

I tried to compare the "amo-request-id" from headers tab and the "id" from Cookies tab but there was no match, but I might be looking in the wrong direction.


Flags: needinfo?(awagner)

The sessionid cookie is set by (AMO). Just browse any AMO page.

Flags: needinfo?(awagner)
Attached image sessionid.png

I didn't find any cookies of the requests in the private browsing mode.

After executing the script in the web console using private mode, I didn't find the request of adding "Ublock" in network panel, I even went through all the request and I the cookies panel was empty for all the request.

I'm not sure what I'm not doing wrong. I attached a screenshot of the cookies section for non-private browsing mode.

Flags: needinfo?(awagner)

Can you check the request for the page?

Flags: needinfo?(awagner)

Also, you might have to log in into AMO.

Hani: for checking the request for ublock, you probably want the network panel in the browser toolbox, not the "normal" developer tools. See .

In the screenshot attached is displayed the only "sessionid" displayed in private browsing mode and the sessionid is not matching the sessionid when using the non-private mode. Cookies panel for Ublock request is displayed empty.

Andreas, can you verify this please, as you reported? Seems the simplest. Thanks.

Flags: needinfo?(awagner)

Tested and verified on Nightly (20190515092556).

Flags: needinfo?(awagner)
Flags: qe-verify+
Whiteboard: [fingerprinting][post-critsmash-triage] → [fingerprinting][post-critsmash-triage][adv-main68+]
Alias: CVE-2019-11723
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.