If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add bugzilla.mozilla.org to xpinstall blacklist



Core Graveyard
Installer: XPInstall Engine
14 years ago
2 years ago


(Reporter: dveditz, Assigned: dveditz)


Dependency tree / graph
Bug Flags:
blocking1.7 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:fix])


(1 attachment)



14 years ago
bug 240552 comment 59 raised the possibility of an attacker opening a
whitelisted site in a frame and poking its DOM to launch an install. That
shouldn't be possible due to the same-origin policy, but just about anybody
could add an install-launching bugzilla attachment fairly anonymously and then
load that in a frame/window.


14 years ago
Flags: blocking1.7?
Whiteboard: [sg:fix]

Comment 1

14 years ago
Created attachment 150460 [details] [diff] [review]
add to blacklist

Comment 2

14 years ago
Not blocking 1.7--we're going to turn off the whitelisting for the release until
we get some UI for it and we don't want bugzilla testcase attachments to
mysteriously fail in the meanwhile.
Flags: blocking1.7? → blocking1.7-

Comment 3

14 years ago
Instead of having mozilla.org on the whitelist and the subdomain
bugzilla.mozilla.org on the blacklist, how about having update.mozilla.org on
the whitelist?

Comment 4

14 years ago
That's definitely what Ben's going to do for Firefox. I thought that was too
restrictive, but maybe we'd only need updates.mozilla.org and ftp.mozilla.org
for the suite.  There are probably some test cases on www.mozilla.org, but
testers could easily add that one themselves.

Comment 5

13 years ago
We don't need to fix this one as long as we don't whitelist mozilla.org.
Currently the plan is to whitelist only update.mozilla.org
Group: security
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.