1410106 - (CVE-2017-7843) fingerprinting users in private window using web-worker + indexedDB

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[Konark Modi - @konarkmodi]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce:

It's possible to fingerprint users in private window by first-party and third-party scripts
1. Can be tracked even after browser restarts.
2. Can be tracked even after user clears Everything. (history / cookies / offline data )

Demo:
1. Visit the test page in normal window and private window:
https://cdn.cliqz.com/browser-f/fun-demo/test-webworker-indexed-db.html

It increments visit count, from inside the web-worker and on the page. Both using indexedDB as the storage.
Visit count this point should be 1. Meaning new unique visit.

2. Now restart the browser and visit the page again in both normal and private window.
It increments the counter to 2. Which means private-window behaviour is not as intended. The expectation is that the user is still treated as a new user.

Repeat the steps after selecting clearing everything in `clear recent history`, the counter still increments.




Actual results:

This is a serious bug, as it can be exploited for moving tracking from cookies to web-workers + indexedDB and have a persistent UUID. Which makes it possible to track a user irrespective of private window, across websites.

Also, as per the MDN documentation and this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=781982 , private window should not have access to IndexedDB but as demonstrated web workers are able to use IndexedDB


Expected results:

1. Private window should not have access to IndexedDB even via web workers.
2. IndexedDB state should be cleaned after closing private window.

Although if the user has disabled `always` accept third-party cookies, the attack is only possible as a first-party, but even then I think private window should not allow tracking even from a first-party perspective.

Should also respect clear history / cookies / storage signal

Comment 1

[Daniel Veditz [:dveditz]]

Either I'm not understanding the steps or I can't reproduce this on Nightly (58).

Comment 2

[Daniel Veditz [:dveditz]]

(In reply to Konark from comment #0)
> Repeat the steps after selecting clearing everything in `clear recent
> history`, the counter still increments.

That's currently expected (other bugs filed) because IndexedDB isn't cleared based on time, only if you "forget about this site".

Matt can reproduce the PB IndexedDB persisting across a restart.

Comment 3

[Konark Modi - @konarkmodi]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> Either I'm not understanding the steps or I can't reproduce this on Nightly
> (58).

I tested the steps on Nighty 58 now, and it's reproducible. It does not work, if you  user sets third-party cookie settings changed to `from visited` or `never`. However, even in that case loading as first party should work.

Let me know, if I should improve the steps to reproduce.

Comment 4

[Konark Modi - @konarkmodi]

(In reply to Daniel Veditz [:dveditz] from comment #2)
> (In reply to Konark from comment #0)
> > Repeat the steps after selecting clearing everything in `clear recent
> > history`, the counter still increments.
> 
> That's currently expected (other bugs filed) because IndexedDB isn't cleared
> based on time, only if you "forget about this site".
> 
As far as I checked, `Forget about this site` does not completely mitigate this attack. My understanding is the following:
1. There is no way to forget about a site that the user visits in PB? Assuming the user never visited that site as a first party in normal mode.

2. AFAIK, "Forget about this site", does not have an option to forget about a third-party site which can track a user, since most likely the user never visited it. If a third-party is using the above exploit, then would be interesting to see, how to delete the indexedDB for that.

> Matt can reproduce the PB IndexedDB persisting across a restart.

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to Konark from comment #3)
> It does not work, if you  user sets third-party cookie settings changed to `from visited` or `never`.

Thanks-- that was my problem.

(In reply to Konark from comment #4)
> 1. There is no way to forget about a site that the user visits in PB?

Yes, because the assumption is that when you close the session we forget everything. Not doing that for IndexedDB is a major failing. I also find it surprising because I know we have tested this and I would hope we have automated tests to ensure it.

Comment 6

[Christiane Ruetten [INACTIVE]]

I'm surprised to hear that PB is writing site-specific data to the profile at all. Once it's in the file system's blocks, it's out of control and will never really go away again.

Comment 7

[Konark Modi - @konarkmodi]

(In reply to Daniel Veditz [:dveditz] from comment #5)
> (In reply to Konark from comment #3)
> > It does not work, if you  user sets third-party cookie settings changed to `from visited` or `never`.
> 
> Thanks-- that was my problem.
But because first-party can also access indexedDB in PB via workers, it should also work without changing the settings for third party cookies.

Comment 8

[Daniel Veditz [:dveditz]]

Andrew: assigned this to you because I don't know how long Ehsan will be "away". You could also talk to Wennie about whether :groovecoder would be an appropriate assignee as he's trying to learn this area.

Comment 9

[Andrew Overholt [:overholt]]

I heard Luke is interested in working on this.

Comment 10

[Luke Crouch [:groovecoder]]

Yeah, I'll jump into it. Will plan to get fixed for 58, so if I don't have a fix this week I'll ping back here to get some extra help next week.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 58. It is pretty late to get a fix in 57 but not impossible.

Comment 12

[Andrea Marchesini [:baku]]

Attachment: idb.patch

Comment 13

[Jan Varga [:janv]]

Comment on attachment 8925587 [details] [diff] [review]
idb.patch

I think Andrew has better knowledge of the private browsing flags.

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8925587 [details] [diff] [review]
idb.patch

Review of attachment 8925587 [details] [diff] [review]:
-----------------------------------------------------------------

Ugh, yeah, when recently looking at this code very recently I was worried about this exact situation and had a to-do to attempt to repro.

In terms of uplift we *ABSOLUTELY* need this on 57.

Restating the problem:
- Under the existing code, IDBFactory:mPrivateBrowsingMode is the source of authority for whether to treat the context as in private browsing mode.  This is separately tracked from the OriginAttributes because of the annoying invariant that a system-principaled docshell can be in private browsing mode, but it will not have the OriginAttribute set, because we can't mutate the singleton system principal.
- IDBFactory::CreateForWindow propagates mPrivateBrowsingMode correctly.
- IDBFactory::CreateForWindow does not.

Restating the solution:
- Stop propagating the private browsing mode separately from the OriginAttribute.
- Rely on the OriginAttribute

The one minor wrinkle in this is the aforementioned "I'm a system-principaled private browsing docshell and I naively attempt to use IDB and the only thing stopping me from logging private browsing data is the existing check."  I don't think code is doing this right now because of the assertion at http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/dom/indexedDB/IDBFactory.cpp#625 but I think we do want to have a guard that ensures that in the system-principal case, if nsILoadContext::UsePrivateBrowsing() is true, we either early fail or explicitly crash.

Comment 15

[Georg Koppen]

One interesting thing we found is that some users are hitting crashes reliably due to this bug in our ESR 52-based Tor Browser:

#0  mozilla::dom::quota::QuotaObject::DisableQuotaCheck (this=0x0)
    at /home/debian/build/tor-browser/dom/quota/ActorsParent.cpp:2714
#1  0x00007ffff39cf5ad in mozilla::dom::indexedDB::(anonymous namespace)::DatabaseConnection::DisableQuotaChecks (
    this=0x7fffcac91580) at /home/debian/build/tor-browser/dom/indexedDB/ActorsParent.cpp:11355
#2  mozilla::dom::indexedDB::(anonymous namespace)::Database::StartTransactionOp::DoDatabaseWork (this=0x7fffcac79040, 
    aConnection=0x7fffcac91580) at /home/debian/build/tor-browser/dom/indexedDB/ActorsParent.cpp:14927
#3  0x00007ffff39cf10e in mozilla::dom::indexedDB::(anonymous namespace)::TransactionDatabaseOperationBase::RunOnConnectionThread (this=this@entry=0x7fffcac79040) at /home/debian/build/tor-browser/dom/indexedDB/ActorsParent.cpp:23735
#4  0x00007ffff39cf28a in mozilla::dom::indexedDB::(anonymous namespace)::Database::StartTransactionOp::RunOnConnectionThread
    (this=0x7fffcac79040) at /home/debian/build/tor-browser/dom/indexedDB/ActorsParent.cpp:14914
#5  0x00007ffff39c71b4 in mozilla::dom::indexedDB::(anonymous namespace)::TransactionDatabaseOperationBase::Run (
    this=0x7fffcac79040) at /home/debian/build/tor-browser/dom/indexedDB/ActorsParent.cpp:23906
#6  0x00007ffff28ca7b1 in nsThread::ProcessNextEvent (this=0x7fffcc480590, aMayWait=<optimized out>, aResult=0x7fffc1888ccf)
    at /home/debian/build/tor-browser/xpcom/threads/nsThread.cpp:1216
#7  0x00007ffff28e53b5 in NS_ProcessNextEvent (aThread=<optimized out>, aThread@entry=0x7fffcc480590, 
    aMayWait=aMayWait@entry=true) at /home/debian/build/tor-browser/xpcom/glue/nsThreadUtils.cpp:361
#8  0x00007ffff39b9e55 in mozilla::dom::indexedDB::(anonymous namespace)::ConnectionPool::ThreadRunnable::Run (
    this=0x7fffcc0aaca0) at /home/debian/build/tor-browser/dom/indexedDB/ActorsParent.cpp:13539
#9  0x00007ffff28ca7b1 in nsThread::ProcessNextEvent (this=0x7fffcc480590, aMayWait=<optimized out>, aResult=0x7fffc1888dff)
    at /home/debian/build/tor-browser/xpcom/threads/nsThread.cpp:1216
#10 0x00007ffff28e53b5 in NS_ProcessNextEvent (aThread=<optimized out>, aThread@entry=0x7fffcc480590, 
    aMayWait=aMayWait@entry=false) at /home/debian/build/tor-browser/xpcom/glue/nsThreadUtils.cpp:361
#11 0x00007ffff2bb0f81 in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x7fffcc4085c0, aDelegate=0x7fffc70b9d50)
    at /home/debian/build/tor-browser/ipc/glue/MessagePump.cpp:338
#12 0x00007ffff2b81b1c in MessageLoop::RunHandler (this=<optimized out>)
    at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:225
#13 MessageLoop::Run (this=this@entry=0x7fffc70b9d50)
    at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:205
#14 0x00007ffff28c953f in nsThread::ThreadFunc (aArg=0x7fffcc480590)
    at /home/debian/build/tor-browser/xpcom/threads/nsThread.cpp:467
#15 0x00007ffff7f96ec7 in _pt_root (arg=0x7fffcc0630c0)
    at /home/debian/build/tor-browser/nsprpub/pr/src/pthreads/ptthread.c:216
#16 0x00007ffff7bc3494 in start_thread (arg=0x7fffc1889700) at pthread_create.c:333
#17 0x00007ffff6c51abf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

The crash does not happen if they are not in Private Browsing Mode (PBM). I have not debugged this problem but I guess the code is not tested for this particular case (as everyone was assuming IndexedDB is off in PBM anyway).

I guess this would go away with the proposed patch, right?

Comment 16

[Georg Koppen]

For more details about the crashing and steps to reproduce see: https://trac.torproject.org/projects/tor/ticket/24040

Comment 17

[Luke Crouch [:groovecoder]]

I did a quick hg import of this patch, then mach build and mach run. But I still see the same error/behavior as comment #0?

Comment 18

[Andrea Marchesini [:baku]]

Comment on attachment 8925587 [details] [diff] [review]
idb.patch

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

It's not about exploiting this bug, it's about using IDB in workers in privateBrowsing mode.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

No. Just a generic PrincipalInfo.attrs() check.

Which older supported branches are affected by this flaw?

All.

If not all supported branches, which bug introduced the flaw?

Bug 994190

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

Not too complex.

How likely is this patch to cause regressions; how much testing does it need?

low. The bug was introduced by a 'temporary' TODO if-statement.

Comment 19

[Andrea Marchesini [:baku]]

(In reply to Luke Crouch [:groovecoder] from comment #17)
> I did a quick hg import of this patch, then mach build and mach run. But I
> still see the same error/behavior as comment #0?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a3f8f2017d7494f0c733f71e2c8b0b928b181433

I pushed to try. Can you check it again with this build? Locally it works correctly.

Comment 20

[Andrew Sutherland [:asuth] (he/him)]

Attachment: browser test of IndexedDB open calls in window/dedicatedworker/sharedworker in normal and PB windows

Here's a test that passes for me with :baku's fix and fails for me without :baku's fix applied.

These are what the failures look like WITHOUT the patch applied:
The following tests failed:
24 INFO TEST-UNEXPECTED-FAIL | dom/indexedDB/test/browser_private_idb.js | IndexedDB does not work in a private-browsing Worker. - Got created, expected error
Stack trace:
chrome://mochikit/content/browser-test.js:test_is:1010
chrome://mochitests/content/browser/dom/indexedDB/test/browser_private_idb.js:null:147
25 INFO TEST-UNEXPECTED-FAIL | dom/indexedDB/test/browser_private_idb.js | IndexedDB does not work in a private-browsing SharedWorker. - Got created, expected error

We of course *do not* want to land the tests concurrently with the bug because they make the problem super obvious.  That said, there's not much doubt about the fix patch patching a hole in something related to private browsing and IDB.

Comment 21

[Jan Varga [:janv]]

Comment on attachment 8925768 [details] [diff] [review]
browser test of IndexedDB open calls in window/dedicatedworker/sharedworker in normal and PB windows

Review of attachment 8925768 [details] [diff] [review]:
-----------------------------------------------------------------

Nice, thanks.

Comment 22

[Luke Crouch [:groovecoder]]

(In reply to Andrea Marchesini [:baku] from comment #19)
> I pushed to try. Can you check it again with this build? Locally it works
> correctly.

Ah yes, I was testing with a fast build. Now I got it to work with your build and with a local binary build.

Comment 23

[Al Billings [:abillings - ex-MoCo]]

sec-approval+ for trunk. This isn't going to make 57 or ESR52.5.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8a46aeb0b562

Comment 25

[Andrew Sutherland [:asuth] (he/him)]

Jan, we're also going to need QuotaManager cleanup logic for this in a follow-up.  Specifically, after running the test I created, I ended up with the directory "storage/default/http+++example.com^privateBrowsingId=1" with an "idb" directory in the testing profile.  (Which was empty because the test deletes the database once it's done with it.)

Should we just add cleanup logic during the quota initialization sweep, or should we do a minor version change bump?

Comment 26

[Andrew Sutherland [:asuth] (he/him)]

:ritu, is this something you can authorize a ride-along or last-minute RC landing for 57?  I really need to emphasize:
*THIS IS/WAS A SERIOUS GAP IN OUR PRIVATE BROWSING IMPLEMENTATION*.

The fallout is:
- A site in private browsing can persistently store data in the user's profile using IndexedDB from a Worker thread.  This data will be accessible from future private browsing sessions in an affected browser, but not from non-private browsing sessions.  The data is still partitioned like a container was used.  So something like "browse to bluenile.com in private browsing, close private browsing window, close firefox, start firefox, start privatebrowsing, browse to bluenile.com" will result in the data previously stored in indexeddb still being accessible.
- The name of the site the user visited in private browsing mode will be visible in the profile directory.  So in the above example, there'd be a "https+++bluenile.com^privateBrowsingId=1".
- Any IDB storage used by the site will show up under our about:preferences "Site Data" "Settings..." storage UI that enumerates origins and their storage used.  The UI will successfully clear the private browsing origin, but that's obviously going to be disconcerting for the users.
- If the site created one or more IDB databases but deleted them, then the origin will not show up in that storage UI, even though the profile directory that clearly identifies the site origin was visited and that it was visited in private browsing mode will exist and continue to exist.  (Until we implement and land a fix for patch 25, but since that will be a somewhat more blatant patch, we do want to land that separately and later.)

To reiterate the good news:
- Private Browsing does operate like a container because of our OriginAttributes mechanism, so the data is partitioned from non-private-browsing, and will be unable to communicate with windows on the same origin not in private-browsing mode, etc.

Comment 27

[Jan Varga [:janv]]

(In reply to Andrew Sutherland [:asuth] from comment #25)
> Jan, we're also going to need QuotaManager cleanup logic for this in a
> follow-up.  Specifically, after running the test I created, I ended up with
> the directory "storage/default/http+++example.com^privateBrowsingId=1" with
> an "idb" directory in the testing profile.  (Which was empty because the
> test deletes the database once it's done with it.)
> 
> Should we just add cleanup logic during the quota initialization sweep, or
> should we do a minor version change bump?

Hm, so after the fix, we should never create storage/default/http+++example.com^privateBrowsingId=1 directory because CheckPermission() is called before we call EnsureOriginIsInitialized(), right ?

Are you worried about such directories that were created before the fix ?

Comment 28

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jan Varga [:janv] from comment #27)
> Hm, so after the fix, we should never create
> storage/default/http+++example.com^privateBrowsingId=1 directory because
> CheckPermission() is called before we call EnsureOriginIsInitialized(),
> right ?

Yes.
 
> Are you worried about such directories that were created before the fix ?

Exactly.

Comment 29

[Jan Varga [:janv]]

(In reply to Andrew Sutherland [:asuth] from comment #28)
> (In reply to Jan Varga [:janv] from comment #27)
> > Hm, so after the fix, we should never create
> > storage/default/http+++example.com^privateBrowsingId=1 directory because
> > CheckPermission() is called before we call EnsureOriginIsInitialized(),
> > right ?
> 
> Yes.
>  
> > Are you worried about such directories that were created before the fix ?
> 
> Exactly.

In that case, I think a minor upgrade is not optimal, since if the user goes back to a previous version, create some dirs with ^privateBrowsingId=1 and then goes back to the original version, these dirs won't be cleared.

Major version change bump would be better, but as we know that's a pain in the ass ...
So for now I would do it as part of the quota initialization sweep and once there's a good reason to do a major version change bump, we can move the cleanup there.

Comment 30

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Andrew, I am willing to consider this one for RC2 (which we will gtb tomm) if security team agrees this is a low risk change.

Dan, Al, I know in comment 23, your recommendation was not to take this in 57. Based on comment 25, do you believe this is worth uplifting in RC2? Please let me know. If this needs more bake time, we can consider uplifting this in a 57.x dot release. Thanks for your help!

Comment 31

[Daniel Veditz [:dveditz]]

We need to land this on ESR-52 whenever we ship this on the main release. Are we ready to get a backport and take it there, too?

I agree this is a bad PB bug and the fix doesn't appear risky.

Comment 32

[Al Billings [:abillings - ex-MoCo]]

If Dan sees no issues, we can take it.

Comment 33

[Al Billings [:abillings - ex-MoCo]]

(Assuming we do both...)

Comment 34

[Sylvestre Ledru [:Sylvestre]]

Really sorry guys, this is too late for 57 :(
We are going to do a rc3 this week end but in case we have any potential regression caused by this patch, we won't be able to ship 57 on Tuesday...

However, as dot releases are still a thing, we could take this as ride along (meaning that we would have to do a dot release for esr too).

Comment 35

[Andrew Overholt [:overholt]]

Andrew told me he's running a local ESR52 build with the patch here to see if it works (and will otherwise make an ESR52-specific patch). He'll ask for esr52 approval there so we can land that at the same time as 57.x. Thanks, Andrew!

Comment 36

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8925587 [details] [diff] [review]
idb.patch

Both the patch and the test graft to esr52 (and release) successfully.  See:
- Comment 18 for the security approval request.
- Comment 23 for security approval.
- Comment 26 for general fallout of the bug.


[[ESR Approval Request Comment]]
This is sec-high.  See next approval request for all other Q's.


[[Release Approval Request Comment]]
[Feature/Bug causing the regression]:
Bug 994190, Firefox 35, IndexedDB on workers.

[User impact if declined]:
See Comment 26 for details, but, in short, Private Browsing is broken in DOM Workers.

[Is this code covered by automated tests?]:
The non-Private-Browsing aspects are covered.  Because so many internal Gecko subsystems depend on IndexedDB (in non-PB mode), we have massive end-to-end coverage on top of the extensive IndexedDB tests.  The problem is that we didn't have enough tests of where it's not expected to work.

Attachment 8925768 [details] [diff] on this bug has been created to provide automated coverage going forward, and was tested against (then-trunk) 58, current release (just now), and current esr52 (just now) with and without the patch to verify the test correctly detects the failure and the fix correctly fixes it.  The plan is to land that test once the esr52 point release and 57 point release have happened.

[Has the fix been verified in Nightly?]:
Yes, 2017-11-08, 14 days ago per Bugzilla.

[Needs manual test from QE? If yes, steps to reproduce]:
No, but comment 0 has a test case if someone really wanted to.

[List of other uplifts needed for the feature/fix]:
No other uplifts required.

[Is the change risky?]:
No, it's the best.

[Why is the change risky/not risky?]:
It's a minimal change in how we propagate a single boolean related to private browsing, eliminating the edge-cases between content pages and workers.  As noted in automated test coverage discussion, the tree would turn VERY orange if we got it wrong.

[String changes made/needed]:
No changes made.

Comment 37

[Andrew Sutherland [:asuth] (he/him)]

(messing with 57 flags in case it helps the bugzilla queries for approval requests).

Comment 38

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8925587 [details] [diff] [review]
idb.patch

Thanks Andrew for your due diligence on this uplift nomination. We've decided to take this one due to the user impact and also since it has baked for a while on Nightly58/59, Release57+.

Liz, will let you drive the ESR dot release

Comment 39

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8925587 [details] [diff] [review]
idb.patch

Taking this for ESR 52.5.1, important privacy fix. 

This is the most organized uplift request ever! Thanks!

Comment 40

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/55236000eb15

Comment 41

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/f6216ea8b8fc4ff0c22f95e0aae6c4df2a5e6b5f

Comment 42

[Andrei Vaida [:avaida]]

(In reply to Andrew Sutherland [:asuth] from comment #36)
> [Is this code covered by automated tests?]:
> The non-Private-Browsing aspects are covered.  Because so many internal
> Gecko subsystems depend on IndexedDB (in non-PB mode), we have massive
> end-to-end coverage on top of the extensive IndexedDB tests.  The problem is
> that we didn't have enough tests of where it's not expected to work.
> 
> Attachment 8925768 [details] [diff] on this bug has been created to provide
> automated coverage going forward, and was tested against (then-trunk) 58,
> current release (just now), and current esr52 (just now) with and without
> the patch to verify the test correctly detects the failure and the fix
> correctly fixes it.  The plan is to land that test once the esr52 point
> release and 57 point release have happened.
> 
> [Has the fix been verified in Nightly?]:
> Yes, 2017-11-08, 14 days ago per Bugzilla.
> 
> [Needs manual test from QE? If yes, steps to reproduce]:
> No, but comment 0 has a test case if someone really wanted to.

Has automated coverage, does not need manual testing - per Andrew.

Comment 43

[Konark Modi - @konarkmodi]

Hi, just tested it on FF 57.0.1, could not reproduce it there. 

But I did not see any information about this security fix in release notes for 57.0.1,
https://www.mozilla.org/en-US/firefox/57.0.1/releasenotes/

Comment 44

[Andrew Sutherland [:asuth] (he/him)]

Thanks for testing the new release (and originally reporting!!).  The security team can weigh in with the specifics, but I believe we're waiting for the ESR52 dot release and probably for time for users to update to the new version to disclose the CVE and specific vulnerabilities fixed.  I too am interested in the answer since that impacts when I can land the test!

Comment 45

[Al Billings [:abillings - ex-MoCo]]

(In reply to Konark from comment #43)

> But I did not see any information about this security fix in release notes
> for 57.0.1,
> https://www.mozilla.org/en-US/firefox/57.0.1/releasenotes/

We had an issue getting ESR52.5.1 out the door. Since this issue is also fixed in that release, we don't want to disclose it before we get a new build out. It was originally going to be in the last day or so but we've been delayed until at least Monday.

Advisories don't go in the release notes anyway. It will be on the Known Vulnerabilities page for the release at https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/

Andrew, you won't be able to land the test before Christmas. We want the release with the fix out and with a high uptake before we land a test that shows the vulnerability.

Comment 46

[Konark Modi - @konarkmodi]

(In reply to Al Billings [:abillings] from comment #45)
> (In reply to Konark from comment #43)
> 
> > But I did not see any information about this security fix in release notes
> > for 57.0.1,
> > https://www.mozilla.org/en-US/firefox/57.0.1/releasenotes/
> 
> We had an issue getting ESR52.5.1 out the door. Since this issue is also
> fixed in that release, we don't want to disclose it before we get a new
> build out. It was originally going to be in the last day or so but we've
> been delayed until at least Monday.
Thanks for the details, I did not realize ESR52.5.1 was not released yet, I saw it on the FTP and thought it's released (https://ftp.mozilla.org/pub/firefox/releases/52.5.1esr/mac/ - it's a 404 now), so will wait for a new update to test.

> Advisories don't go in the release notes anyway. It will be on the Known
> Vulnerabilities page for the release at
> https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/
> Andrew, you won't be able to land the test before Christmas. We want the
> release with the fix out and with a high uptake before we land a test that
> shows the vulnerability.

Comment 47

[Konark Modi - @konarkmodi]

Is it safe to remove the secure flag from this bug now?