storage.onChanged should not trigger for storageArea session in content scripts
Categories
(WebExtensions :: Storage, defect, P2)
Tracking
(firefox-esr102 unaffected, firefox-esr115 verified, firefox115 wontfix, firefox116 verified, firefox117 verified)
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | verified |
firefox115 | --- | wontfix |
firefox116 | --- | verified |
firefox117 | --- | verified |
People
(Reporter: robwu, Assigned: zombie)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [addons-jira])
Attachments
(4 files)
1.56 KB,
application/zip
|
Details | |
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-release-
diannaS
:
approval-mozilla-esr115+
|
Details | Review |
23.95 KB,
image/png
|
Details | |
23.82 KB,
image/png
|
Details |
The storage.session
API as implemented in bug 1823713 is supposed to limit the visibility of the storage to the extension process. Content scripts are not supposed to see the data, especially because the opt-in through the setStorageAccess
method has not been implemented (bug 1823717).
The implementation however exposes the data through the storage.onChanged
event: https://searchfox.org/mozilla-central/rev/9a4666e63199bd1bcfc9095f6efec3488c358458/toolkit/components/extensions/parent/ext-storage.js#76,82-85,93
STR:
- Load the attched add-on, e.g. at about:debugging.
- Visit example.com
- Click on the extension button. That will register
storage.onChanged
in the content script, and callstorage.session.set
,storage.local.set
,storage.sync.set
, and then display the receivedstorage.onChanged
events. - Look at the results.
Expected:
- The output should list "local" and "sync"
Actual:
- The output lists "session", "local" and "sync"
Note: extension developers affected by this: Use the StorageArea-specific onChanged
listener instead of the global storage.onChanged
listener to receive events for specific storage areas. That feature was introduced in Firefox 101 (bug 1758475).
Updated•2 years ago
|
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Set release status flags based on info from the regressing bug 1823713
:zombie, since you are the author of the regressor, bug 1823713, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Comment 2•2 years ago
|
||
There is already a pending needinfo on :zombie
:robwu could you provide some additional details around the impact. For example:
- We had one extension hit problems with Fx115 (Bug 1838448), do you expect that other extensions may hit this?
- Is this something we want to include a fix for in a Fx115 dot release?
Assignee | ||
Updated•2 years ago
|
Reporter | ||
Comment 3•2 years ago
|
||
(In reply to Donal Meehan [:dmeehan] from comment #2)
There is already a pending needinfo on :zombie
:robwu could you provide some additional details around the impact. For example:
- We had one extension hit problems with Fx115 (Bug 1838448), do you expect that other extensions may hit this?
The reporter of that other bug confirmed that they weren't affected by this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1838448#c15). Other extensions that do could be affected. The API is relatively new and the API usage is relatively low.
- Is this something we want to include a fix for in a Fx115 dot release?
Yes. The feature is meant to be used to store potentially sensitive data of extensions, notably password managers, and we should not be sending this data to (untrusted) web content processes. Tom will fix this and request an uplift.
Assignee | ||
Comment 4•2 years ago
|
||
Comment 6•2 years ago
|
||
bugherder |
Comment 7•2 years ago
|
||
The patch landed in nightly and beta is affected.
:zombie, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox116
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 8•2 years ago
|
||
I'm going to ask for uplift to release 115 as well, in case there's a dot release planned.
Assignee | ||
Comment 9•2 years ago
•
|
||
Comment on attachment 9343266 [details]
Bug 1842009 - Don't send session area storage.onChanged events to content scripts r?robwu
Beta/Release Uplift Approval Request
- User impact if declined: We introduced an API in 115, with unwanted behavior that exposes storage.session events to content scripts. This new area is stored in memory, and often used for decrypted data, such as password manager's vaults. While this isn't a vulnerability in itself, it expands the potential attack surface if another part of the browser (or extension) is compromised.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): One additional condition in code that's well understood and not particularly complicated.
- String changes made/needed: none
- Is Android affected?: Yes
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Because of the long lifetime of ESR, the potential for an exploit to use this bug to compromise user's data is higher.
- User impact if declined: Same as above.
- Fix Landed on Version: 117
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Same as above, this code hasn't changes since 115.
Comment 10•2 years ago
|
||
Comment on attachment 9343266 [details]
Bug 1842009 - Don't send session area storage.onChanged events to content scripts r?robwu
Approved for 116.0b5
Comment 11•2 years ago
|
||
uplift |
Updated•2 years ago
|
Comment 12•2 years ago
•
|
||
Comment on attachment 9343266 [details]
Bug 1842009 - Don't send session area storage.onChanged events to content scripts r?robwu
Approved for 115.1esr
Comment 13•2 years ago
|
||
uplift |
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Verified as Fixed. Tested on the latest Nightly (117.0a1/20230713214846) and Beta (116.0b5/20230713175905) under Windows 10 x64 and macOS 11.3.1.
The output lists only “local” and “sync” and NOT “session”, confirming the fix. For more details, see the attached screenshot.
Once ESR 115.1 is available, I’ll verify there too.
Comment 15•2 years ago
|
||
Comment 16•2 years ago
|
||
Comment on attachment 9343266 [details]
Bug 1842009 - Don't send session area storage.onChanged events to content scripts r?robwu
We aren't planning any more dot releases this cycle. This fix will ship in 116/115.1esr going out on August 1.
Updated•2 years ago
|
Assignee | ||
Comment 17•2 years ago
•
|
||
Sounds good, thanks Alex and Ryan.
Comment 18•2 years ago
|
||
Verified as Fixed. Tested on the latest ESR (115.1.0esr/20230724124053) under Windows 10 x64 and Ubuntu 22.04 LTS.
The output lists only “local” and “sync” and NOT “session”, confirming the fix. For more details, see the attached screenshot.
Comment 19•2 years ago
|
||
Description
•