(In reply to Arminius (Armin Ebert) from comment #1)
Thanks for the clear explanation. It's midnight here and so I don't have time to reproduce myself, but I have some questions to get us going...
- Next, an SVG image with embedded script code is downloaded. As is default behavior since FF 97, the file downloads and opens automatically in a new tab from within the user's download dir.
Can you clarify why you think this is new since 97? SVGs have opened in the browser since bug 1639067 (Firefox 81), AIUI.
- The SVG's script triggers an addon installation of
addon.xpi.part which pops up the confirmation dialog.
Dan or Mike, do you have any intuitions as to how much would break if we started rendering
file: SVGs loaded as toplevel docshell items as image documents (ie without running script), and/or how "web"-incompatible that would be?
- The download stream for
addon.xpi is now closed, causing the browser to rename
FWIW, this behaviour has always existed on macOS... so it's not clear to me that this is really new for 97, though the scope may have been more limited before)
- Now, a fake addon package is downloaded as
addon.xpi.part, thus taking the place of the file that the current install dialog refers to. By pre-caching the download, this switch can be done sufficiently fast.
Would using a strong random number generator for the part file name help against this attack?
- If the user now confirms the dialog, the browser installs and executes the fake addon (while still referring to the previously parsed manifest) without re-confirming integrity.
This seems like a serious issue with the add-on install process, especially if it applies special mozilla privileges to non-mozilla add-ons. Rob/Shane/Luca/Tomislav?