automated extension scanning is security theater (and here's code to prove it)

Dan Stillman dan at danstillman.com
Mon Nov 23 09:15:06 UTC 2015


People who follow the mozilla.addons.user-experience list will know that 
we (Zotero) have been asking for several months to be whitelisted for 
extension signing. If you haven't been following, 1) lucky you, and 2) 
you can read my initial post about it [1], which gives some context. The 
upshot is that, if changes aren't made to the signing process, we'll 
have no choice but to discontinue Zotero for Firefox when Firefox 43 
comes out on December 15, because we'll be stuck in manual review 
forever and unable to release timely updates to our users.

It's been a maddening discussion, with Mozilla folks repeatedly 
suggesting that Zotero — a leading research tool put out by a large 
public research university as a non-profit open-source project and 
recommended by nearly every university worldwide — will either turn 
rogue or become an attack vector if we're allowed to continue releasing 
it unimpeded as we have for nine years.

There seems to finally be a growing consensus [2] around the need for a 
whitelist for extensions like Zotero, but forward progress is still 
being held up by a belief that the new signing system meaningfully 
protects users from front-loaded malware and that a whitelist is 
inherently more dangerous. I'd like to put that argument to rest for 
good, both for Zotero and for extensions that might not qualify for 
whitelisting. I'm posting to this list because I think there needs to be 
a broader discussion of the assumptions underlying the signing system, 
and I don't see that happening on the other list.

Here's an extension I created in a few minutes:

https://github.com/dstillman/amo-validator-bypass

It does three things:

1) It monitors HTTP(S) requests for Basic Auth credentials and POSTs 
them to an arbitrary HTTP server. (I chose Basic Auth because it was 
easy, but it could be cookies, page content, or any other sort of 
sensitive data.)

2) When a given URL is loaded, it runs an arbitrary local process.

3) When another given URL is loaded, it downloads arbitrary JS code from 
a remote server and runs it with chrome privileges.

This extension passes the AMO validator with no signing warnings, 
meaning it would be automatically signed for distribution. #1 required 
no modifications to pass validation. #2 and #3 required some l33t 
hacking in the form of Components.interfaces["nsI" + "p".toUpperCase() + 
"rocess"] and window['e'.replace() + 'val'](req.responseText).

This would be shocking if it weren't so obvious. I asked in February how 
the scanner would possibly catch things like this, and Jorge's response 
was that most malware authors are lazy and that he believed the scanner 
could be made to "block the majority of malware". The fact that, nine 
months later, and a few weeks before an enforcement deadline that was 
already postponed by several months, I can write a trivial extension in 
a few minutes that steals passwords, runs a local process, and executes 
arbitrary remote code, but that is still automatically signed, 
demonstrates just how ill-conceived this scheme is. It also destroys any 
argument that whitelisting would put users at greater risk for malware, 
and it's infuriating that I've had to waste the last few months arguing 
about the dangers of a whitelisted Zotero. And it's just depressing that 
the entire developer community spent the last year debating extension 
signing and having every single counterargument be dismissed only to end 
up with a system that is utterly incapable of actually combating malware.

A system that takes five minutes to circumvent does not "raise the bar" 
in any real way — it raises the bar just enough for legitimate 
developers to trip on it, while malware authors will simply step over 
it. It does not "balance" user safety and developer freedom — it 
provides essentially none of the former, while pointlessly impeding 
developers who are inclined to follow the rules. It's not that it's "not 
a perfect solution" or still needs refinement — it literally does not 
work. Front-loaded unlisted extensions should be trusted exactly as much 
as they were previously, and it's dangerous and irresponsible for 
Mozilla to suggest otherwise.

And a transparently broken system doesn't need to be defended just 
because it was designed by people from Mozilla.

Here's what I would suggest:

1) Stop pretending you can meaningfully combat malware via automated 
scanning. Accept that signing gives you enforcement of add-on ids, a 
record of deployed code, and a mechanism for combating malicious 
side-loaded extensions, which were the primary target of this scheme to 
begin with. These are all meaningful improvements from the pre-signing era.

2) For front-loaded extensions, cut down the set of tests that block 
automatic signing to minification (though that's easy to disguise too) 
and things that almost unambiguously indicate problems — settings or 
APIs that are almost never valid to touch or that cause serious 
performance/reliability problems. Goodbye (extremely) lazy 
malware/problemware developers. Everything else should be left in as 
notifications for conscientious developers to fix if necessary and for 
AMO editors to review if they so choose at a later date. There's no 
point trying to block usage of nsIProcess or js-ctypes, because anyone 
who wants to use them for nefarious purposes will be able to do so 
regardless, so you're only punishing developers who have valid reasons. 
Deal with those things via a permissions system in WebExtensions. Don't 
block an extension for ambiguous AMO rules like on* or innerHTML — this 
isn't AMO, you're not manually reviewing all extensions, and you 
therefore can't make any guarantees to users about their safety, so 
don't get in the way of legitimate developers who may have perfectly 
valid reasons for using those things. The more onerous the process, the 
more developers will either stop developing for Firefox or just take 
simple steps to avoid the scanner altogether, and the less code you'll 
have on record. Review new front-loaded extensions to add some friction 
to the signup process and perhaps to give some helpful guidance, but 
know that the code can be changed to do anything later. Review signed 
extensions periodically and notify developers or blacklist them if you 
find legitimate issues.

3) Set up a whitelist for any front-loaded unlisted extensions that have 
good reasons for hitting the "almost unambiguous" flags (or that simply 
time out, as in the case of Zotero), acknowledging that whitelisting 
isn't allowing them to do anything they couldn't already do before.

4) Be grateful that you changed course before you had to read in the 
tech press about malware that was automatically signed by the system you 
spent a year and a lot of good will developing.

Whether or not you follow these suggestions, please stop claiming that a 
whitelisted Zotero would be a greater threat to users than any other 
unlisted extension and implement a whitelist before signing is enforced 
so that we can continue offering the tool we've produced for the Firefox 
community for the last decade.

- Dan


[1] 
https://groups.google.com/d/msg/mozilla.addons.user-experience/lU5WZmwS4Qc/rpT55LhrCwAJ
[2] 
https://groups.google.com/d/topic/mozilla.addons.user-experience/vxpElfVe_uo/discussion




More information about the firefox-dev mailing list