automated extension scanning is security theater (and here's code to prove it)
Dan Stillman
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
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
Dan Stillman
validator-bypassing proof-of-concept — a skeleton extension with three
tiny examples of unblockable code patterns, hard-coded to localhost —
was to add it to the Firefox blocklist:
https://bugzilla.mozilla.org/show_bug.cgi?id=1227605
Can someone please step in and restore sanity here? This is well past
being an embarrassment to Mozilla.
FYI, a version of my post with some additional context [1] has been on
Hacker News and is currently on the front pages of r/linux and
r/technology on Reddit, and it's been viewed thousands of times today.
[1]
http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
David Rajchenbach-Teller
I'm not sure that Jorge is in charge of signing, though. Does anybody on
this list know who is behind that feature?