Closed
Bug 806543
Opened 12 years ago
Closed 11 years ago
Block malicious 'pink' add-ons
Categories
(Toolkit :: Blocklist Policy Requests, defect)
Toolkit
Blocklist Policy Requests
Tracking
()
RESOLVED
FIXED
People
(Reporter: jorgev, Assigned: jorgev)
References
Details
Attachments
(2 files)
While investigating bug 806451, I noticed another pattern in the IDs, that pointed me to a series of add-ons that have ids starting with 'pink' and ending in '.info'. At least one of them has been blocked before (https://addons.mozilla.org/en-US/firefox/blocked/i84). We should block all of them.
Assignee | ||
Comment 1•12 years ago
|
||
This block is now staged: https://addons-dev.allizom.org/en-US/firefox/blocked/i217 We need to test it on Nightly in order to verify the fix for bug 806534. I'm attaching an XPI that should be blocked by this. It's not a real sample because we don't have any XPI other than the one on bug 743484, but that one is already blocked.
Assignee | ||
Comment 2•12 years ago
|
||
We need QA to verify this hardblock on staging. It needs to be tested on Nightly, using the test extension attached.
Keywords: qawanted
QA Contact: anthony.s.hughes
After pinging staging, my blocklist.xml file contains: <emItem blockID="i217" id="/^pink@.*\.info$/i"> <versionRange minVersion="0" maxVersion="*" severity="3"></versionRange> </emItem> However, I'm not seeing any dialogs warning me about the extension and it remains enabled in the Add-ons Manager.
I see the following in about:support: [Pink Add-on | 1.0 | true | pink@plugin-tema-rosa.info]
Assignee | ||
Comment 5•12 years ago
|
||
This was pushed today, so it'll have to wait for the next Nightly release (tomorrow, I presume). Sorry for that.
Tested using Firefox Nightly 20.0a1 2012-11-28 * Pinging blocklist before add-on install blocks the installation of the Pink add-on * Pinging blocklist after add-on install displays the hardblock UI and disables the Pink add-on * Add-ons Manager does not give an option to re-enable the add-on This looks good to me.
Comment 7•12 years ago
|
||
Can we roll this out with a minimum version of FF19 today (since bug 806534 will be in Aurora tomorrow), and then FF18 and up next week?
Assignee | ||
Comment 8•12 years ago
|
||
Blocked in production, Firefox 19.0a1 and above: https://addons.mozilla.org/en-US/firefox/blocked/i238
Trying to test this with Firefox Nightly 19.0a1 20121109030635 and this does not appear to be working; Pink add-on remains enabled. Aftering pinging the production blocklist I have the following in my blocklist.xml: <emItem blockID="i238" id="/^pink@.*\.info$/"> <versionRange minVersion="0" maxVersion="*" severity="3"> <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> <versionRange minVersion="19.0a1" maxVersion="*"/></targetApplication> </versionRange> </emItem> However, the add-on remains unblocked after using the browser for 15 minutes. If I start Firefox 20.0a1 2012-12-10 with the same profile the add-on is blocked due to "security or stability issues".
Keywords: qawanted
Assignee | ||
Comment 10•12 years ago
|
||
This was pushed to mozilla-central on 2012-11-27, so you would need to test on a nightly version newer than that. I think we want to test the Aurora version, though, so 19.0a2 will do.
Keywords: qawanted
Comment 11•12 years ago
|
||
Okay, I guess I was confused by the "19.0a1" in the blocklist.xml file. I confirm that 19.0a2 and 20.0a1 both block the Pink add-on attached to this bug using the production blocklist.
Keywords: qawanted
Assignee | ||
Comment 12•12 years ago
|
||
This has been updated in production to cover Firefox 18.0 and up. Please give it at least an hour before testing.
Keywords: qawanted
Comment 13•11 years ago
|
||
This is not working with 18.0b3, should it? From blocklist.xml: <emItem blockID="i238" id="/^pink@.*\.info$/"> <versionRange minVersion="0" maxVersion="*" severity="3"> <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> <versionRange minVersion="18.0" maxVersion="*"/> </targetApplication> </versionRange> </emItem>
Assignee | ||
Comment 14•11 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #13) > This is not working with 18.0b3, should it? I thought that the UA for Beta was already the final one, 18.0 without any beta additions like b3. What is the UA string for b3?
Comment 15•11 years ago
|
||
User Agent from about:support: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Assignee | ||
Comment 16•11 years ago
|
||
Tested on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/20100101 Firefox/18.0 and works as expected. Can you verify, please?
Comment 17•11 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #16) > Tested on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) > Gecko/20100101 Firefox/18.0 and works as expected. Can you verify, please? Specifically, which version of Firefox 18 is this? (ie. which Beta)
Assignee | ||
Comment 18•11 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #17) > (In reply to Jorge Villalobos [:jorgev] from comment #16) > > Tested on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) > > Gecko/20100101 Firefox/18.0 and works as expected. Can you verify, please? > > Specifically, which version of Firefox 18 is this? (ie. which Beta) It should be the latest beta (don't know the number). I just checked for updates and there were none.
Comment 19•11 years ago
|
||
So this is works now with 18.0b4. * blocklist ping before add-on install blocks installing the add-on * blocklist ping after add-on install triggers a hardblock However it does not seem to work with 18.0b3. Shouldn't this block be working for all Firefox 18 builds?
Assignee | ||
Comment 20•11 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19) > However it does not seem to work with 18.0b3. Shouldn't this block be > working for all Firefox 18 builds? The fix for bug 806534 was uplifted to beta on December 10th, and 18.0b3 was built on December 5th, so your observations are correct and match expectations.
Comment 21•11 years ago
|
||
Okay, thanks Jorge. Given that I think we can call this fixed.
Keywords: qawanted
Assignee | ||
Comment 22•11 years ago
|
||
Thanks, Anthony. We need one more verification, on ESR 17. Since we don't want the prod block to cover anything below 18, this needs to be tested with the staged block: https://addons-dev.allizom.org/en-US/firefox/blocked/i237 However, I think there's no published version of the ESR with this patch. Alex, can you confirm this and tell Anthony which branch to use for testing?
Flags: needinfo?(akeybl)
Keywords: qawanted
Comment 23•11 years ago
|
||
(In reply to Jorge Villalobos [:jorgev] from comment #22) > Thanks, Anthony. We need one more verification, on ESR 17. Since we don't > want the prod block to cover anything below 18, this needs to be tested with > the staged block: > > https://addons-dev.allizom.org/en-US/firefox/blocked/i237 > > However, I think there's no published version of the ESR with this patch. > Alex, can you confirm this and tell Anthony which branch to use for testing? Anthony grabs the nightlies of ESR17 to test, so this shouldn't be an issue.
Flags: needinfo?(akeybl)
Keywords: verifyme
Comment 24•11 years ago
|
||
Firefox 17.0.1esrpre 2012-12-19 accepts the staged block, in that the Pink add-on is hardblocked following a blocklist ping to staging.
Assignee | ||
Comment 25•11 years ago
|
||
Firefox 18 was released, so we can call this fixed with the block on prod.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: addons.mozilla.org → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•