Leaking all bookmarks when a user tries to view a malicious bookmark URL from the exported bookmarks HTML file
Categories
(Firefox :: Bookmarks & History, defect, P2)
Tracking
()
People
(Reporter: luan.herrera, Assigned: freddy)
References
()
Details
(Keywords: sec-low, Whiteboard: [post-critsmash-triage][adv-main97+r])
Attachments
(2 files)
An attacker can steal all the user's bookmarks if the steps described below are done at any point in time by the victim.
The core of the issue is that bookmark URLs can be javascript URIs that will execute javascript when accessed from the exported bookmarks HTML file.
Note that although the attack takes a few steps to work, they are normal actions that don't need to occur at the same time and that they can happen organically.
- The user adds a malicious URL to their bookmarks.
- Later on, the user exports their bookmarks through the "Export Bookmarks to HTML" functionality (the exported file is an HTML).
- The user opens the exported bookmarks HTML file and clicks on the malicious URL.
- The URL is a malicious javascript URI that will execute in the context of the local file and will be able to steal all the user's bookmarks.
A simple fix would be to add a Content Security Policy using a <meta> tag to the <head> of the exported bookmarks HTML file.
Here's an unlisted video simulating the attack:
https://youtu.be/_6zUg-FtHe0
VERSION
Version: 93.0 (64-bit)
Operating System: Windows 10
REPRODUCTION CASE
- Access https://lbherrera.github.io/lab/firefox/bookmarks-7633458/index.html
- Drag the link to the bookmarks bar (or add it to your bookmarks some other way).
- Access the "Manage bookmarks" menu.
- Click on "Import and Backup" and then in the "Export Bookmarks to HTML..." option.
- Save the HTML file and open it.
- Click on the "Add me to your bookmarks" link that was previously added.
- A malicious javascript will run in the context of the local bookmarks HTML file and would be able to leak all the victim's bookmarked URLs.
I have also attached the file used in the PoC - if you prefer, you can reproduce it by downloading and hosting index.html on a web server.
CREDIT INFORMATION
Reporter credit: Luan Herrera (@lbherrera_)
|
||
Comment 1•3 years ago
|
||
Marco, can you take a look?
|
||
Comment 2•3 years ago
|
||
Bookmarklets are known to be dangerous and this would be a very convoluted attack, but you're right that it makes very little sense to run a bookmarklet in the context of the exported bookmarks page. A <meta> CSP is a great idea for making this safer
|
Reporter | |
Comment 3•3 years ago
|
||
Hey Daniel, I agree that the current attack is convoluted. While thinking for another way to exploit this, I realized it would be possible to exploit this from a malicious HTML file running locally that scanned the user's local files looking for the exported bookmarks page somewhere in the victim's filesystem and then do a clickjacking attack as a way to get the victim to click in the malicious bookmarklet. Still somewhat convoluted, but I guess less so.
|
||
Comment 4•3 years ago
|
||
We also don't export bookmarks.html by default, unless you explcitly set a pref. That format is only kept as a compatibility format to export bookmarks to third parties, and it's only accessible from a menu of the Library window, I don't think it's very widely used, like for Nightly I see about 700 pings, and 1500 in Beta.
Any ideas to harden it are of course well accepted.
|
|
||
Comment 5•2 years ago
|
||
Unfortunately we are not awarding a bug bounty: this is not the default behavior for export and most users don't have bookmarklets.
|
Assignee | |
Comment 6•2 years ago
|
||
Adding a <meta> Content-Security-Policy here https://searchfox.org/mozilla-central/rev/f465d324513f09dbe33ed79fabe6a9ef98aa51ca/toolkit/components/places/BookmarkHTMLUtils.jsm#932 should be really easy.
It would break bookmarklets, but they are probably a lot less useful when clicked from a bookmarks.html anyway. Opinions, mak?
|
|
||
Comment 7•2 years ago
|
||
I'm fine with the added <meta>, as well as breaking bookmarklets when clicking on bookmarks.html. We should just do it.
|
|
Assignee | |
Comment 8•2 years ago
|
||
This changeset adds a Content-Security-Policy to HTML documents for
exported bookmarks. The change will stop bookmarklets from working
directly, which is not breaking the use case in which a bookmarklet
is intended to modify an existing page. It will affect the use
case where you have a full website/application stored in a bookmarklet
that was supposed to replace the current web page. In this case, users
can right-click and select "copy link".
N.B.: The CSP does not mean that we invite you or anyone else to
look for other html/style injection bugs. HTML export is not the
default export method and we don't expect injections in here to be
a severe attack vector.
|
||
Updated•2 years ago
|
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 9•2 years ago
|
||
add Content-Security-Policy to bookmarks HTML export r=mak
https://hg.mozilla.org/integration/autoland/rev/c8f53ad9796cb90f833205d772134297ce8369f0
https://hg.mozilla.org/mozilla-central/rev/c8f53ad9796c
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Comment 10•2 years ago
|
||
Verified as fixed on Windows 10 x64, macOS 11.6 and on Ubuntu 20.04 x64.
|
|
Assignee | |
Comment 11•2 years ago
|
||
I got a release tracking alert for ESR, but I'm not sure this is the kind of bug we'd want to uplift. The security risk is... minuscule and I think it might annoy some users. WDYT?
|
|
||
Comment 12•2 years ago
|
||
We can wontfix. It's an old bug and sec-low.
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
Description
•