Addon downloads are stored until tmp dir gets cleaned (can cause issues on systems using tmpfs) and should instead be cleaned up as soon as the user makes a choice regarding the install
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
People
(Reporter: andreien, Unassigned)
Details
(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
If a user navigates to install an addon, for example https://addons.mozilla.org/firefox/downloads/file/4047353/ublock_origin-1.46.0.xpi, the file for the addon is stored until system restart whether or not the user decides to install the extension.
On Linux, this is stored in /tmp/tmp-[RANDOM_STRING].xpi. If a large extension (a few gigabytes, for example) is downloaded, this will leave the user out of RAM. In most cases, clearing /tmp is only automatically triggered upon a full system restart. The user is unlikely to know where the file is stored and remove it manually because the browser does not announce or keep track of the download location like generic file downloads.
This may affect other operating systems, though I am unable to verify myself due to lack of access.
Since this file is unused after the user decides to cancel or install the addon (a new, separate file is created whenever the same addon is downloaded again), I think it would make sense to remove this temporary file when user interaction is finished, and the user decides to cancel or install the addon.
Reproduced on Nightly, Mozilla Firefox 110.0a1 20221230044034 20221230044034.
Comment 1•2 years ago
|
||
I assume the security flag was added by accident here, as comment 0 doesn't really indicate why this would be a security issue as such. There's no way for a malicious site to trigger this, AIUI, because Firefox uses an allowlist of sites able to install add-ons.
(In reply to Andrei Enache from comment #0)
On Linux, this is stored in /tmp/tmp-[RANDOM_STRING].xpi. If a large extension (a few gigabytes, for example) is downloaded, this will leave the user out of RAM.
Only if they're using tmpfs
or similar to store /tmp
in RAM, which AIUI isn't the default on Ubuntu and other large distros.
In most cases, clearing /tmp is only automatically triggered upon a full system restart.
Again, I don't believe this is the case on Ubuntu and other large distros, cf. https://askubuntu.com/a/983848 says this now happens once a day if there's no reboot.
Reporter | ||
Comment 2•2 years ago
|
||
I see what you mean. The allowlist is not really an issue here, since the addon doesn't have to be malicious per se to cause issues, just have a large xpi.
Thanks for letting me know, I was not aware other distros do not mount /tmp as tmpfs.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•8 months ago
|
Description
•