On 11/5/13 5:21 AM, Henri Sivonen wrote:
> On Mon, Nov 4, 2013 at 11:12 PM, Jorge Villalobos <
jo...@mozilla.com> wrote:
>> We can't effectively stop an EXE running locally with admin privileges.
>
> Right.
>
>> We can try to make it harder for these installers to inject malware into
>> Firefox, but a sufficiently determined attacker will find a way. We're
>> trying to block the less sophisticated attacks (which we believe are
>> most of them) and prevent other types of attack that we know are
>> possible but aren't happening widely (as far as we know).
>
> How likely it is that the outcome of this effort is that the attackers
> raise their level of sophistication
Some probably will, but others won't. It really depends on the incentive
behind their attacks. In some cases it will be worth doing the extra
effort, but I suspect in most cases it won't. If you have a malicious
binary running with admin privileges in the user's system I think there
are more attractive targets than spamming users' Facebook walls or
changing their search settings or default pages. And even if they all
did, we would not be worse off than we are today.
> and Firefox suffers marketshare
> and goodwill damage from private extensions becoming too hard to
> maintain and deploy (leaving us with both attacks and
> marketshare/goodwill damage)?
There are different categories of private extensions that I think need
to be handled separately.
There are internal enterprise add-ons, which we're trying to address in
this proposal by offering different ways to override the system. There's
the whitelist pref, blocking the API URL, creating a proxy for it (see a
recent response by Blair about it), or possibly offering a signing
certificate. Deploying any of these has some cost, but we're trying to
make it as low as possible.
The majority of non-AMO add-on installs we track could be classified as
greyware. It's mostly the toolbar add-ons that range from the absolutely
unwelcome to the seemingly necessary (like what is bundled with AV
software). Since these are mostly about monetization and most developers
are willing to modify their software to comply with our policies (when
they are threatened with blocklisting), I expect them to just register
their add-ons. If they decide to subvert our system we will have to
chase them around and find ways to make them comply, like we do now. My
only concern for this category is that we get the more user desired
add-ons (the AV ones) on board so users don't have them blocked.
There are add-ons that are distributed outside of AMO out of convenience
or because the developers chose not to deal with our admittedly slow
review process, or their add-on was rejected by us for some reason.
These are add-ons we don't know much about but for the most part have
relatively little usage. It's possible that some of them decide to let
their add-ons break because they don't want to deal with AMO, but I
wouldn't expect that to have a huge impact in terms of usage.
Then are also non-AMO abandoned add-ons, where one possible solution is
to just register them ourselves to reduce friction during the transition.
> Is there an articulation of what threats exactly this proposal is
> designed to address and why those threats are worth addressing in an
> environment where attackers can escalate by putting the malicious code
> inside their installer .exes?
The document lists the main motivations behind this proposal:
* There are numerous add-on IDs being distributed and installed in the
wild that the Add-ons Team have no knowledge about. Many are believed to
be generated per-install.
* Finding contact information for add-on developers can be a daunting
task, when sometimes all the Add-ons Team have is an add-on ID and a name.
* Finding file samples of these add-ons can be just as difficult.
I think Johnath put it very well in his message. There will be a group
of developers who will realize they're doing things wrong and fall in
line, while there will be others who will continue avoiding our system,
or avoid it more overtly. If we can use this system to reduce this
problem, and have better control over add-on IDs and malware out there,
I think that's a big gain for our users. We're balancing this with the
inconvenience for non-AMO developers and some non-AMO add-on users, but
we believe the net effect will be positive.
>> Unwanted toolbar installs is something we already deal with at a policy
>> level and using blocklisting as the hammer, and it has yielded positive
>> results so far.
>
> In the blocklisting bugs I've followed, the blocklisting process has
> been terribly slow. It's been a while though since I've paid
> attention. How long does it take these days to get a deceptively
> installed toolbar blocked?
It's variable since it's a manual process where the I'm right in the
middle of the critical path. Our resources are extremely limited, so I
haven't been able to reach a point where I can guarantee specific
response times.
In some cases we blocklist on the day the bug is filed, which is
generally when the add-on is clearly malicious or there's no way to
contact the developer. In the murkier cases we contact the developer,
usually as soon as the bug is filed, and then give them 2-3 weeks to
respond. If there's no response, we block. If they respond then this
becomes much less predictable because of development timelines and back
and forth between us and the developers.
The sources of truth here would be the list of blocked add-ons, linking
to the bugs, and the list of open blocklist bugs:
https://addons.mozilla.org/en-US/firefox/blocked/
https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Blocklist%20pending&sharer_id=189742&list_id=8483185
>> I responded to the
>> certificate proposals in other replies on this thread.
>
> Do you mean "The
> first one is that we would need to set a cut-off point after which we
> only allow signed files. That would exclude all installations of
> previously unsigned files, which would be massive."?
Yes. Mike replied with more comments, which I need to follow up on.