Re: Dan Stillman's concerns about Extension Signing

[Gervase Markham]

On 27/11/15 15:50, Gavin Sharp wrote:
> No, that's not right. There's an important distinction between
> "finding malicious JS code" and "finding _all_ malicious JS code". The
> latter is impossible, but the former isn't.
> 
> Proving "the validator won't catch everything" isn't particularly
> relevant when it isn't intended to, in the overall add-on signing
> system design.

If the validator is open source, which it is, then anyone who wants to
get code past it can just use it as an oracle until it passes.
Therefore, given malicious intent, I would expect the validator not to
catch _anything_.

We need to base the system on reputation, not on code scanning. We can
either hand out code signing certs and do the reputation based on them,
or have an _automated_ code signing portal and tie the reputation to the
accounts on that. As cert revocation doesn't work well, the latter seems
to offer much more control and to be the better plan.

If we accept, as you seem to, that no system can catch everything, then
I think the right "not catching everything" is the risk of AMO
high-reputation account compromise. Having that as your weak spot allows
the building of a system where people like Dan, who have high
reputation, can automatically sign as many builds as they want and,
fundamentally, keep shipping products. Which is what we all want.

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Jorge Villalobos]

On 11/30/15 1:53 PM, Ehsan Akhgari wrote:
> On 2015-11-30 10:29 AM, David Rajchenbach-Teller wrote:
>> Could we perhaps organize a MozLando workshop to discuss add-ons
>> security?
> 
> I think you need to reach out to the add-ons team.  I was not involved
> in any of the design process; I just happened to note the same issues as
> Dan noticed after the fact.
> 

We've added a session on Thursday afternoon. You can find it on Sched.

Jorge
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gijs Kruitbosch]

On 29/11/2015 02:56, Dan Stillman wrote:

You can block known malware signatures with the scanner if you think
that's a good use of time. But that doesn't require blocking valid APIs
and patterns that have legitimate uses. That's what we're discussing
here. AV software doesn't result in long delays in legitimate software
updates so that AV vendors can manually review software.


It doesn't work the same way because AV vendors have no control over 
what apps the OS is letting run, but if it did, it would cause the same 
problems. Quick bugzilla search:


https://bugzilla.mozilla.org/show_bug.cgi?id=1116819
https://bugzilla.mozilla.org/show_bug.cgi?id=1168855
https://bugzilla.mozilla.org/show_bug.cgi?id=1095049
https://bugzilla.mozilla.org/show_bug.cgi?id=799980

I haven't looked at the bugs, but they are a small sample of a large set 
of bugs, and it's just a fact that we (just like other legitimate 
software developers) occasionally get flagged by various 
anti-virus/malware software.


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gavin Sharp]

That's one of the suggestions Dan Stillman makes in his post, and it
seems like a fine idea to me.

Gavin

On Mon, Nov 30, 2015 at 11:15 AM, Jonathan Kew  wrote:
> On 30/11/15 15:45, Gavin Sharp wrote:
>>>
>>> and it's definitely the wrong thing to do.
>>
>>
>> Fundamentally the add-on signing system was designed with an important
>> trade-off in mind: security (ensuring no malicious add-ons are
>> installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring
>> that building and distributing add-ons is as easy as it can be).
>>
>> If your proposed alternative plan is "get rid of automatic signing", then
>> we know that it's going to significantly hamper Mozilla's ability to
>> maintain a healthy add-on ecosystem, and harm what were considered some
>> important add-on use cases. I don't think it strikes the right balance.
>>
>> If your proposed alternative plan is something else, maybe it would help
>> to
>> clarify it.
>>
>
> Perhaps if there were a mechanism whereby "trusted" add-on developers could
> have their add-ons -- or even just updates for
> previously-reviewed-and-signed add-ons -- automatically signed without
> having to jump through the validator/review hoops each time?
>
> How would a developer acquire "trusted" status? By demonstrating a track
> record of producing add-ons that pass AMO review -- which may be a
> combination of automatic validation and/or human review.
>
> And of course any add-on developer who is found to have abused their
> "trusted" status to sign and deploy malicious code would have that status
> revoked, in addition to the malicious add-on being blocked.
>
> ISTM this would maintain most of the intended benefits of the signing
> system, while substantially smoothing the path for developers such as Dan
> who need to deliver frequent updates to their users.
>
> Feasible?
>
> JK
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Thomas Zimmermann]

Hi

Am 27.11.2015 um 16:50 schrieb Gavin Sharp:
> On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham  wrote:
>> But the thing is, members of our security group are now piling into the
>> bug pointing out that trying to find malicious JS code by static code
>> review is literally _impossible_ (and perhaps hinting that they'd have
>> said so much earlier if someone had asked them).
> No, that's not right. There's an important distinction between
> "finding malicious JS code" and "finding _all_ malicious JS code". The
> latter is impossible, but the former isn't.
>
> Proving "the validator won't catch everything" isn't particularly
> relevant when it isn't intended to, in the overall add-on signing
> system design.

I think the fact that the validator (or manual review) cannot catch
everything is very relevant.

Users cannot rely on the review process (automatic or manual), because
it can never catch all bugs (malicious or not). So users still have to
rely on an extension's developers to get their code into good shape;
just as it is currently the case. And I'd guess that malicious code will
get more sophisticated when the review procedures improve.

Another point is that one never knows how close to 'good' an extension
or a review is, because this would require knowledge about the absolute
number of bugs in the extension. Getting this number requires a perfect
validator. So all bugs from a review might get fixed, but the overall
extension is still in the 'crap territory'. I'm a bit surprised that
this hasn't been mentioned here yet.

Therefore I'm skeptical about the effective benefit for the users. The
mandatory review seems to create a promise of security that it cannot
fulfill. Reviews and validation are good things, but holding back an
update for a pending review doesn't seem helpful.

Best regards
Thomas

>
> Gavin
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gavin Sharp]

It looks to me like you're arguing about a separate point (AMO review
requirements for add-on updates), when the subject at hand is the add-on
signing system's reliance on the AMO validator as the only prerequisite for
automatic signing.

Gavin

On Mon, Nov 30, 2015 at 10:30 AM, Thomas Zimmermann  wrote:

> Hi
>
> Am 27.11.2015 um 16:50 schrieb Gavin Sharp:
> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham 
> wrote:
> >> But the thing is, members of our security group are now piling into the
> >> bug pointing out that trying to find malicious JS code by static code
> >> review is literally _impossible_ (and perhaps hinting that they'd have
> >> said so much earlier if someone had asked them).
> > No, that's not right. There's an important distinction between
> > "finding malicious JS code" and "finding _all_ malicious JS code". The
> > latter is impossible, but the former isn't.
> >
> > Proving "the validator won't catch everything" isn't particularly
> > relevant when it isn't intended to, in the overall add-on signing
> > system design.
>
> I think the fact that the validator (or manual review) cannot catch
> everything is very relevant.
>
> Users cannot rely on the review process (automatic or manual), because
> it can never catch all bugs (malicious or not). So users still have to
> rely on an extension's developers to get their code into good shape;
> just as it is currently the case. And I'd guess that malicious code will
> get more sophisticated when the review procedures improve.
>
> Another point is that one never knows how close to 'good' an extension
> or a review is, because this would require knowledge about the absolute
> number of bugs in the extension. Getting this number requires a perfect
> validator. So all bugs from a review might get fixed, but the overall
> extension is still in the 'crap territory'. I'm a bit surprised that
> this hasn't been mentioned here yet.
>
> Therefore I'm skeptical about the effective benefit for the users. The
> mandatory review seems to create a promise of security that it cannot
> fulfill. Reviews and validation are good things, but holding back an
> update for a pending review doesn't seem helpful.
>
> Best regards
> Thomas
>
> >
> > Gavin
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gavin Sharp]

> and it's definitely the wrong thing to do.

Fundamentally the add-on signing system was designed with an important
trade-off in mind: security (ensuring no malicious add-ons are
installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring
that building and distributing add-ons is as easy as it can be).

If your proposed alternative plan is "get rid of automatic signing", then
we know that it's going to significantly hamper Mozilla's ability to
maintain a healthy add-on ecosystem, and harm what were considered some
important add-on use cases. I don't think it strikes the right balance.

If your proposed alternative plan is something else, maybe it would help to
clarify it.

Gavin

On Mon, Nov 30, 2015 at 9:33 AM, Ehsan Akhgari 
wrote:

> On 2015-11-28 2:06 AM, Gavin Sharp wrote:
>
>> The assumption that the validator must catch all malicious code for
>> add-on signing to be beneficial is incorrect, and seems to be what's
>> fueling most of this thread.
>>
>
> It would be really helpful if we can get past defending the add-on
> validator; the only thing that everyone is this thread seems to agree on is
> the list of things it is capable of doing.
>
> The problem is how we're using it seems to not make sense according to
> what it can and does do.
>
> > Validation being a prerequisite for
>
>> automatic signing is not primarily a security measure, but rather just a
>> way of eliminating "obvious" problems (security-related or otherwise)
>> from installed and enabled add-ons generally.
>>
>
> Successful validation is currently not merely a prerequisite for automatic
> signing of non-AMO add-ons, it is also a sufficient condition.  Let me
> repeat the part of my previous response which you didn't reply to:
>
> "The specific problem here is that we allow automatic signing of
> extensions once they pass the add-on validator checks, and we allow our
> users to run signed extensions without any other checks.  Therefore, the
> current system is vulnerable to attacks such as what Dan's PoC extension
> has demonstrated."
>
> Perhaps that is not what was supposed to happen, but we're doing this for
> a fact, and it's definitely the wrong thing to do.
>
> > With add-on singing fully
>
>> implemented, if (when) malicious add-ons get automatically signed,
>> you'll have several more effective tools to deal with them, compared to
>> the status quo.
>>
>> Gavin
>>
>> On Nov 27, 2015, at 8:49 PM, Eric Rescorla > > wrote:
>>
>>
>>>
>>> On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari
>>> > wrote:
>>>
>>> On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp
>>> > wrote:
>>>
>>>
>>> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham >> > wrote:
>>> > > But the thing is, members of our security group are now piling
>>> into the
>>> > > bug pointing out that trying to find malicious JS code by static
>>> code
>>> > > review is literally _impossible_ (and perhaps hinting that
>>> they'd have
>>> > > said so much earlier if someone had asked them).
>>> >
>>> > No, that's not right. There's an important distinction between
>>> > "finding malicious JS code" and "finding _all_ malicious JS code".
>>> The
>>> > latter is impossible, but the former isn't.
>>> >
>>>
>>> Note that malicious code here might look like this:
>>>
>>>   console.log("success");
>>>
>>> It's impossible to tell by looking at the code whether that line
>>> prints a
>>> success message on the console, or something entirely different,
>>> such as
>>> running calc.exe.
>>>
>>> A better framing for the problem is "finding some arbitrary
>>> instances of
>>> malicious JS code" vs "finding malicious JS code".  My point in
>>> the bug and
>>> in the discussions prior to that was that a static checker can
>>> only do the
>>> former, and as such, if the goal of the validator is finding
>>> malicious
>>> code, its effectiveness is bound to be a lint tool at best.
>>>
>>>
>>> Indeed.  And if the validator is publicly accessible, let alone has
>>> public
>>> source code, it's likely to be straightforward for authors of malicious
>>> code to evade the validator. All they need to do is run their code
>>> through the validator, see what errors it spits out, and modify the
>>> code until it no longer spits out errors.
>>>
>>> Again, this goes back to threat model. If we're trying to make it easier
>>> for authors to comply with our policies (and avoid writing problematic
>>> add-ons), then a validator seems reasonable. However, if we're trying
>>> to prevent authors of malicious add-ons from getting their add-ons
>>> through, that seems much more questionable, for the reasons listed above.
>>> However, once we accept that we can't stop authors who are 

Re: Dan Stillman's concerns about Extension Signing

[Jonathan Kew]

On 30/11/15 15:45, Gavin Sharp wrote:

and it's definitely the wrong thing to do.


Fundamentally the add-on signing system was designed with an important
trade-off in mind: security (ensuring no malicious add-ons are
installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring
that building and distributing add-ons is as easy as it can be).

If your proposed alternative plan is "get rid of automatic signing", then
we know that it's going to significantly hamper Mozilla's ability to
maintain a healthy add-on ecosystem, and harm what were considered some
important add-on use cases. I don't think it strikes the right balance.

If your proposed alternative plan is something else, maybe it would help to
clarify it.



Perhaps if there were a mechanism whereby "trusted" add-on developers 
could have their add-ons -- or even just updates for 
previously-reviewed-and-signed add-ons -- automatically signed without 
having to jump through the validator/review hoops each time?


How would a developer acquire "trusted" status? By demonstrating a track 
record of producing add-ons that pass AMO review -- which may be a 
combination of automatic validation and/or human review.


And of course any add-on developer who is found to have abused their 
"trusted" status to sign and deploy malicious code would have that 
status revoked, in addition to the malicious add-on being blocked.


ISTM this would maintain most of the intended benefits of the signing 
system, while substantially smoothing the path for developers such as 
Dan who need to deliver frequent updates to their users.


Feasible?

JK

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[David Rajchenbach-Teller]

Could we perhaps organize a MozLando workshop to discuss add-ons security?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Thomas Zimmermann]

Hi

Am 30.11.2015 um 16:40 schrieb Gavin Sharp:
> It looks to me like you're arguing about a separate point (AMO review
> requirements for add-on updates), when the subject at hand is the add-on
> signing system's reliance on the AMO validator as the only prerequisite for
> automatic signing.

OK. Or maybe I used the term 'update' a bit sloppy. My question is: is
it worth holding back an extension because of of a pending review
(either by a tool or human)? I guess updating existing add-ons is the
more common case, compared to signing new one's.

Your reply makes me think that the whole discussion implicitly seems to
assume that a manual review can fix any problems with the automated
tools, or is always better. I would not agree to this. Manual reviews
depend a lot on the reviewer and the reviewer's constitution during the
review. With tools, at least you know what you get.

Best regards
Thomas

>
> Gavin
>
> On Mon, Nov 30, 2015 at 10:30 AM, Thomas Zimmermann > wrote:
>> Hi
>>
>> Am 27.11.2015 um 16:50 schrieb Gavin Sharp:
>>> On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham 
>> wrote:
 But the thing is, members of our security group are now piling into the
 bug pointing out that trying to find malicious JS code by static code
 review is literally _impossible_ (and perhaps hinting that they'd have
 said so much earlier if someone had asked them).
>>> No, that's not right. There's an important distinction between
>>> "finding malicious JS code" and "finding _all_ malicious JS code". The
>>> latter is impossible, but the former isn't.
>>>
>>> Proving "the validator won't catch everything" isn't particularly
>>> relevant when it isn't intended to, in the overall add-on signing
>>> system design.
>> I think the fact that the validator (or manual review) cannot catch
>> everything is very relevant.
>>
>> Users cannot rely on the review process (automatic or manual), because
>> it can never catch all bugs (malicious or not). So users still have to
>> rely on an extension's developers to get their code into good shape;
>> just as it is currently the case. And I'd guess that malicious code will
>> get more sophisticated when the review procedures improve.
>>
>> Another point is that one never knows how close to 'good' an extension
>> or a review is, because this would require knowledge about the absolute
>> number of bugs in the extension. Getting this number requires a perfect
>> validator. So all bugs from a review might get fixed, but the overall
>> extension is still in the 'crap territory'. I'm a bit surprised that
>> this hasn't been mentioned here yet.
>>
>> Therefore I'm skeptical about the effective benefit for the users. The
>> mandatory review seems to create a promise of security that it cannot
>> fulfill. Reviews and validation are good things, but holding back an
>> update for a pending review doesn't seem helpful.
>>
>> Best regards
>> Thomas
>>
>>> Gavin
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Bobby Holley]

(Gingerly wading into this thread and hoping not to get sucked in)

Given the fundamental limits of static analysis, dynamic analysis might be
a better approach. I think we can do a reasonable job (with the help of
interpositions) of monitoring the various escape points at which addon code
might do arbitrary dangerous things, without actually preventing it from
doing those things in a way that would break lots of addons. We could then
keep an eye on what addons are doing in the wild, and revoke the signatures
for the addon / developer if we find them to be misbehaving.

I proposed this in [1] and it got filed separately as [2]. Detailed
follow-up discussion is probably better to do in that bug.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1199628#c26
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1227464


On Mon, Nov 30, 2015 at 8:25 AM, Gavin Sharp  wrote:

> That's one of the suggestions Dan Stillman makes in his post, and it
> seems like a fine idea to me.
>
> Gavin
>
> On Mon, Nov 30, 2015 at 11:15 AM, Jonathan Kew  wrote:
> > On 30/11/15 15:45, Gavin Sharp wrote:
> >>>
> >>> and it's definitely the wrong thing to do.
> >>
> >>
> >> Fundamentally the add-on signing system was designed with an important
> >> trade-off in mind: security (ensuring no malicious add-ons are
> >> installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring
> >> that building and distributing add-ons is as easy as it can be).
> >>
> >> If your proposed alternative plan is "get rid of automatic signing",
> then
> >> we know that it's going to significantly hamper Mozilla's ability to
> >> maintain a healthy add-on ecosystem, and harm what were considered some
> >> important add-on use cases. I don't think it strikes the right balance.
> >>
> >> If your proposed alternative plan is something else, maybe it would help
> >> to
> >> clarify it.
> >>
> >
> > Perhaps if there were a mechanism whereby "trusted" add-on developers
> could
> > have their add-ons -- or even just updates for
> > previously-reviewed-and-signed add-ons -- automatically signed without
> > having to jump through the validator/review hoops each time?
> >
> > How would a developer acquire "trusted" status? By demonstrating a track
> > record of producing add-ons that pass AMO review -- which may be a
> > combination of automatic validation and/or human review.
> >
> > And of course any add-on developer who is found to have abused their
> > "trusted" status to sign and deploy malicious code would have that status
> > revoked, in addition to the malicious add-on being blocked.
> >
> > ISTM this would maintain most of the intended benefits of the signing
> > system, while substantially smoothing the path for developers such as Dan
> > who need to deliver frequent updates to their users.
> >
> > Feasible?
> >
> > JK
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Ehsan Akhgari]

On 2015-11-30 10:29 AM, David Rajchenbach-Teller wrote:

Could we perhaps organize a MozLando workshop to discuss add-ons security?


I think you need to reach out to the add-ons team.  I was not involved 
in any of the design process; I just happened to note the same issues as 
Dan noticed after the fact.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[emiliano . heyns]

On Monday, November 30, 2015 at 8:57:42 PM UTC+1, Dan Stillman wrote:
> On 11/30/15 6:24 AM, Gijs Kruitbosch wrote:
> > This seems like something we should be able to get data about. (I do 
> > not have such data.) Have you asked anyone?
> 
> If it's only Zotero that's affected by this, then we should have been 
> whitelisted three months ago when we first asked about it.

And the number is skewed in any case, as there will be extensions (such as 
mine) who neuter functionality in order to avoid having to go through manual 
review. So I would be put in the "not affected" pile even though I *am* 
effected.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Dan Stillman]

Just to give some context here, we've been asking for a "trusted author" 
whitelist for three months. Gijs even helpfully proposed specific rules. 
The reason things came to this point is that it was still being argued 
as of last week that the whitelist was inherently more dangerous by 
allowing whitelisted developers to do malicious things and evade 
detection. We can now see that's not true — non-whitelisted extensions 
can do the same thing, trivially.


We've assumed that Zotero would be whitelisted, but that doesn't help 
other legitimate extension developers if the whitelist is designed with 
an assumption that a whitelisted extension is more dangerous. The 
proposed rules were still going to restrict whitelist status to 
extensions with large numbers of users.


Given what we know now, I can't see a justification for not 
"whitelisting" (meaning allowing an automated review override) any 
demonstrably legitimate developer. In terms of malware, you'd have to 
argue that someone who bought, compromised, or developed a legitimate 
extension would then be unable or unwilling to rewrite one line to get 
code past the validator. In terms of potentially insecure code (e.g., 
innerHTML), you'd have to argue that those patterns posed sufficient 
risk to users over the next several days that blocking an extension 
update (which possibly contained other important bug fixes that 
definitely affected users) made sense, as opposed to AMO reviewers 
looking at them after the fact and asking for immediate fixes or 
blocklisting depending on severity (and rescinding "whitelist" 
privileges if there's a pattern of ignoring issues).


I've gone further and argued that, given the ease of a validator bypass, 
just doing an initial manual review for the first release of any 
front-loaded unlisted extension would be the meaningful blocking step, 
but that's not as important. I just don't want to see obviously 
legitimate developers of existing extensions blocked for no reason.


On 11/30/15 2:52 PM, Ehsan Akhgari wrote:

That sounds like a good idea to me as well.

On 2015-11-30 11:25 AM, Gavin Sharp wrote:

That's one of the suggestions Dan Stillman makes in his post, and it
seems like a fine idea to me.

Gavin

On Mon, Nov 30, 2015 at 11:15 AM, Jonathan Kew  
wrote:

On 30/11/15 15:45, Gavin Sharp wrote:


and it's definitely the wrong thing to do.



Fundamentally the add-on signing system was designed with an important
trade-off in mind: security (ensuring no malicious add-ons are
installed/executed) vs. maintaining a healthy add-on ecosystem 
(ensuring

that building and distributing add-ons is as easy as it can be).

If your proposed alternative plan is "get rid of automatic 
signing", then

we know that it's going to significantly hamper Mozilla's ability to
maintain a healthy add-on ecosystem, and harm what were considered 
some
important add-on use cases. I don't think it strikes the right 
balance.


If your proposed alternative plan is something else, maybe it would 
help

to
clarify it.



Perhaps if there were a mechanism whereby "trusted" add-on 
developers could

have their add-ons -- or even just updates for
previously-reviewed-and-signed add-ons -- automatically signed without
having to jump through the validator/review hoops each time?

How would a developer acquire "trusted" status? By demonstrating a 
track

record of producing add-ons that pass AMO review -- which may be a
combination of automatic validation and/or human review.

And of course any add-on developer who is found to have abused their
"trusted" status to sign and deploy malicious code would have that 
status

revoked, in addition to the malicious add-on being blocked.

ISTM this would maintain most of the intended benefits of the signing
system, while substantially smoothing the path for developers such 
as Dan

who need to deliver frequent updates to their users.

Feasible?

JK


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gijs Kruitbosch]

We have data on pre-signing add-ons that we consider malware, but we 
have no way of knowing (structurally, besides incidental reports on 
bugzilla with the malware uploaded) the contents of the XPIs in question 
and/or whether they would have passed the validator - they wouldn't go 
through the validator, because they would have been distributed outside 
of AMO (front- or sideloaded - either way we would not have source code).


So really, nobody has data on what will happen in a post-signing world. 
There's an interesting question about how much the pre-signing system 
can predict what will happen here, but it's sadly not as clear-cut as 
you hope.


~ Gijs

On 28/11/2015 19:30, Kartikaya Gupta wrote:

So it seems to me that people are actually in general agreement about
what the validator can and cannot do, but have different evaluations
of the cost-benefit tradeoff.

On the one hand we have the camp (let's say camp A) that believes the
validator provides negligible actual benefit, because it is trival to
bypass, but at the same time provides a huge cost to add-on
developers. And on the other hand we have the camp ("camp B") that
believes the validator provides some non-negligible benefit, even
though it may significantly increase the cost to add-on developers.


From what I have been told from multiple people, Mozilla does have

actual data on the type and number of malicious add-ons in the wild,
and it cannot be published. I don't really like this since it goes
against openness and whatnot, but I can accept that there are
legitimate reasons for not publishing this data. So the question is -
do the people in camp A or the people in camp B have access to this
data? I would argue that whoever has access to the data is in a better
position to make the right call with respect to the cost-benefit
tradeoff, and everybody else should defer to them. If people in both
camps have access to the data, then clearly they have different
interpretations of the data and they should discuss it further.
Presumably they know who they are.

kats


On Sat, Nov 28, 2015 at 10:35 AM, Eric Rescorla  wrote:

On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch 
wrote:


On 27/11/2015 23:46, dstill...@zotero.org wrote:


The issue here is that this new system -- specifically, an automated
scanner sending extensions to manual review -- has been defended by
Jorge's saying, from March when I first brought this up until
yesterday on the hardening bug [1], that he believes the scanner can
"block the majority of malware".



Funny how you omit part of the quote you've listed elsewhere, namely:
"block the majority of malware, but it will never be perfect".

You assert the majority of malware will be 'smarter' than the validator
expects (possibly after initial rejection) and bypass it. Jorge asserts,
from years of experience, that malware authors are lazy and the validator
has already been helpful, in conjunction with manual review.



Did Jorge in fact assert that that as a matter of fact or as a matter of
opinion?
Maybe I missed it.

This seems like an empirical question. how many pieces of obvious malware
(in the sense that once the functionality is found it's clearly malicious
code
as opposed to a mistake, not in the sense that it's easy to find the
functionality)
have been found by the review process? How many pieces of obvious malware
(in the sense above) have passed the review process or otherwise been
found in the wild?

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gijs Kruitbosch]

On 28/11/2015 19:42, Dan Stillman wrote:

On 11/28/15 5:06 AM, Gijs Kruitbosch wrote:

On 27/11/2015 23:46, dstill...@zotero.org wrote:

The issue here is that this new system -- specifically, an automated
scanner sending extensions to manual review -- has been defended by
Jorge's saying, from March when I first brought this up until
yesterday on the hardening bug [1], that he believes the scanner can
"block the majority of malware".


Funny how you omit part of the quote you've listed elsewhere, namely:
"block the majority of malware, but it will never be perfect".

You assert the majority of malware will be 'smarter' than the
validator expects (possibly after initial rejection) and bypass it.
Jorge asserts, from years of experience, that malware authors are lazy
and the validator has already been helpful, in conjunction with manual
review. It's not helpful to say that what Jorge is saying is "not
true" - you mean different things when you say "the majority of malware".


I've addressed this repeatedly. In my view, saying "it will never be
perfect" is a misleading statement that betrays a misunderstanding of
the technical issues.


The validator has been used for years for AMO-published add-ons. It is 
in that context that it did what it did, and it did so reasonably well - 
there was always manual review for what the validator didn't catch. Not 
all add-ons would be published on AMO, and there was no reason for 
malware authors to publish on AMO except if they wanted to frontload it 
and have the slightly-less-bumpy install flow that AMO offers because of 
its default whitelist status in terms of sources of XPIs. Some people 
did try this. I have no comprehensive data or anything, but I do not 
believe that there was much if any such malware that made it to "fully 
reviewed" status on AMO.


In that context, saying that the validator blocked the majority of 
malware and would never be perfect was a perfectly valid statement and 
does not imply any lack of technical understanding.


The change that muddies the waters here is that we're now signing 
add-ons, and we're signing the ones that aren't distributed on AMO. We 
do not have source code for non-AMO distributed add-ons pre-signing, and 
so we have no way of knowing how much of that malware would or would not 
be picked up by the validator as-is. It seems likely that, as-is, a lot 
of it would be, because they have had no cause to use any techniques of 
circumvention. It seems equally likely that they would proceed to use 
such techniques in order to get signed anyway.


IOW, I think you're both right, and it would be helpful if you stopped 
attacking Jorge and other folks because I don't think that is a 
constructive discussion to be having.



If the person who's been defending this system for the last year


Jorge does not make decisions in a vacuum, wasn't the only person who 
architected the current solution, isn't some kind of lone dictator, 
doesn't get to decide what the Firefox team does (the team that actually 
implemented signing on the browser side), and he isn't the only person 
to have "defended the system" for whatever definition of system you're 
using here (it's not clear) -- and really, as I have pointed out before, 
even if he was all those things, it would not make "the system" any 
better or worse. Stop making this all about Jorge and his supposed lack 
of understanding. As I have repeatedly said, it is not helpful.




As for what, if anything, should block release without override, I'm
happy to talk specifics, but we can't have a discussion about that
without even agreeing on the point of the validator,


Why do we have to agree (and who are 'we'?) on the 'point' of the 
validator? As it is, the people in this discussion without access to the 
validator's results for zotero (which is almost everybody) have no idea 
what you're running into and which things are bothering you because they 
flag up false positives. For all we know you obfuscate all your code and 
use eval(btoa(...)) all over the place. More seriously, all I remember 
explicitly being mentioned is assigning to innerHTML in documents that 
are not (and won't be) in any docshell and therefore shouldn't be 
exploitable. It would be good to get a broader idea of the issues you're 
actually running into (as I'm assuming there are more than just this 
one, particularly because this one would be pretty easy to fix on your 
side, as you say the line in question only runs under other browsers).


In any case, if you want to insist, here's my view: the point of the 
validator is to raise the bar for both malware and for trivially-found 
security holes in otherwise benign (or seemingly benign / greyware, if 
you assume collusion between the 'benign' add-on submitted and the 
website that will use that add-on's security hole for privilege 
escalation of their website / remote code) add-ons. Raising the bar is 
helpful so that editors don't waste time reviewing script kiddie 

Re: Dan Stillman's concerns about Extension Signing

[Ehsan Akhgari]

On 2015-11-28 2:06 AM, Gavin Sharp wrote:

The assumption that the validator must catch all malicious code for
add-on signing to be beneficial is incorrect, and seems to be what's
fueling most of this thread.


It would be really helpful if we can get past defending the add-on 
validator; the only thing that everyone is this thread seems to agree on 
is the list of things it is capable of doing.


The problem is how we're using it seems to not make sense according to 
what it can and does do.


> Validation being a prerequisite for

automatic signing is not primarily a security measure, but rather just a
way of eliminating "obvious" problems (security-related or otherwise)
from installed and enabled add-ons generally.


Successful validation is currently not merely a prerequisite for 
automatic signing of non-AMO add-ons, it is also a sufficient condition. 
 Let me repeat the part of my previous response which you didn't reply to:


"The specific problem here is that we allow automatic signing of 
extensions once they pass the add-on validator checks, and we allow our 
users to run signed extensions without any other checks.  Therefore, the 
current system is vulnerable to attacks such as what Dan's PoC extension 
has demonstrated."


Perhaps that is not what was supposed to happen, but we're doing this 
for a fact, and it's definitely the wrong thing to do.


> With add-on singing fully

implemented, if (when) malicious add-ons get automatically signed,
you'll have several more effective tools to deal with them, compared to
the status quo.

Gavin

On Nov 27, 2015, at 8:49 PM, Eric Rescorla > wrote:




On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari
> wrote:

On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp
> wrote:

> On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham > wrote:
> > But the thing is, members of our security group are now piling into the
> > bug pointing out that trying to find malicious JS code by static code
> > review is literally _impossible_ (and perhaps hinting that they'd have
> > said so much earlier if someone had asked them).
>
> No, that's not right. There's an important distinction between
> "finding malicious JS code" and "finding _all_ malicious JS code". The
> latter is impossible, but the former isn't.
>

Note that malicious code here might look like this:

  console.log("success");

It's impossible to tell by looking at the code whether that line
prints a
success message on the console, or something entirely different,
such as
running calc.exe.

A better framing for the problem is "finding some arbitrary
instances of
malicious JS code" vs "finding malicious JS code".  My point in
the bug and
in the discussions prior to that was that a static checker can
only do the
former, and as such, if the goal of the validator is finding malicious
code, its effectiveness is bound to be a lint tool at best.


Indeed.  And if the validator is publicly accessible, let alone has public
source code, it's likely to be straightforward for authors of malicious
code to evade the validator. All they need to do is run their code
through the validator, see what errors it spits out, and modify the
code until it no longer spits out errors.

Again, this goes back to threat model. If we're trying to make it easier
for authors to comply with our policies (and avoid writing problematic
add-ons), then a validator seems reasonable. However, if we're trying
to prevent authors of malicious add-ons from getting their add-ons
through, that seems much more questionable, for the reasons listed above.
However, once we accept that we can't stop authors who are trying
to evade detection, then treating it as a linter and allowing authors
to override it seems a lot more sensible.

-Ekr



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Ehsan Akhgari]

On 2015-11-28 8:28 PM, Mike Hoye wrote:

On 2015-11-28 2:40 PM, Eric Rescorla wrote:

How odd that your e-mail was in response to mine, then.


Thanks, super helpful, really moved the discussion forward, high five.

To Ehsan's point that "malicious code here might look like this:
console.log("success"); [and] It's impossible to tell by looking at the
code whether that line prints a success message on the console, or
something entirely different, such as running calc.exe." - that's true,
but it also looks a lot like the sort of problem antivirus vendors have
been dealing with for a long time now. Turing completeness is a thing,
the halting problem exists and monsters are real, sure, but that doesn't
mean having antivirus software is a waste of time that solves no
problems and protects nobody.


As others have pointed, your antivirus analogy is really irrelevant 
here.  Also, may I suggest that starting to say things such as "Turing 
completeness is a thing... and monsters are real" in the discussion 
related to an actual security issue trivializes the discussion to a 
point where important issues will get ignored, as I've seen happen a few 
times before in this thread?



One key claim Stillman made, that  " A system that takes five minutes to
circumvent does not “raise the bar” in any real way", is perhaps true in
an academic sense, but not in a practical one. We know a lot more than
we did a decade ago about the nature of malicious online actors, and one
of the things we know for a fact is the great majority of malicious
actors on the 'net are - precisely as Jorge asserts - lazy, and that
minor speedbumps - sometimes as little as a couple of extra clicks - are
an effective barrier to people who are doing whatever it is they're
about to do because they're bored and it's easy. And that's most of them.


I agree with Jonas about this.  Even if all of the malware we have seen 
on AMO so far have been stuff done by script kiddies, the right way to 
think about this is "maybe we've not seen the more sophisticated ones." 
 It would be terrible to base the security of our add-on ecosystem on 
assumptions about the laziness of the malicious actors.


(Also, anecdotally, some of the exploit code against Firefox from web 
pages that I have seen myself is among the most sophisticated code and 
tricks I've seen in my career so far.)



Any semicompetent locksmith can walk through your locked front door
without breaking stride, but you lock it anyway because keeping out
badly-raised teenagers is not "security theater", it's sensible,
cost-effective risk management.


Please see my reply to Gavin on Friday?  To fit the status quo with this 
analogy, we're currently copying keys to our front door to strangers 
that successfully fill out a questionnaire.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Jonas Sicking]

On Sat, Nov 28, 2015 at 5:28 PM, Mike Hoye  wrote:
> One key claim Stillman made, that  " A system that takes five minutes to
> circumvent does not “raise the bar” in any real way", is perhaps true in an
> academic sense, but not in a practical one. We know a lot more than we did a
> decade ago about the nature of malicious online actors, and one of the
> things we know for a fact is the great majority of malicious actors on the
> 'net are - precisely as Jorge asserts - lazy, and that minor speedbumps -
> sometimes as little as a couple of extra clicks - are an effective barrier
> to people who are doing whatever it is they're about to do because they're
> bored and it's easy. And that's most of them.

I don't understand this claim.

We are talking about malware authors who have decided to write a
Firefox-specific addon, done a bunch of research into how firefox
addons work and then written and debugged a working Firefox addon.

It does not seem likely to me that a person that has gone through all
that trouble would then simply give up after having spent time on all
the other steps. Especially given that in many ways, the other steps
are more work and takes longer to accomplish.

This is also why I think comparison to antivirus software doesn't seem
very fitting. Malware authors know that they don't have have to bother
with working around antivirus software since a lot of people don't
have any antivirus at all. And so not working around it still gives
you benefit for your labor.

Compare that to firefox addons where if you don't work around the
scanner you will soon get literally zero installs. I have a hard time
imagining that malware authors are so lazy that they are ok with that
number.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gijs Kruitbosch]

On 27/11/2015 23:46, dstill...@zotero.org wrote:

The issue here is that this new system -- specifically, an automated
scanner sending extensions to manual review -- has been defended by
Jorge's saying, from March when I first brought this up until
yesterday on the hardening bug [1], that he believes the scanner can
"block the majority of malware".


Funny how you omit part of the quote you've listed elsewhere, namely: 
"block the majority of malware, but it will never be perfect".


You assert the majority of malware will be 'smarter' than the validator 
expects (possibly after initial rejection) and bypass it. Jorge asserts, 
from years of experience, that malware authors are lazy and the 
validator has already been helpful, in conjunction with manual review. 
It's not helpful to say that what Jorge is saying is "not true" - you 
mean different things when you say "the majority of malware".



Jorge has been saying he believes the scanner can block most malware

because he genuinely doesn't understand the technical issues here, as
his statements (and his absurd blocklisting of the PoC) make clear. It's
hard not to make this sound like a personal attack,

This is what's so offensive. It's hard to make this not sound like a 
personal attack because it *is* a personal attack. What's more, Jorge's 
competence or otherwise is irrelevant to the discussion. Your 
insistently bringing it up and your condescending attitude towards Jorge 
and other Mozilla folks is offensive, unhelpful, and not constructive in 
addressing the actual issue at hand. If we were some nameless 
corporation you wouldn't even know the name of the person responsible 
for the add-ons system, but that wouldn't change its quality or the 
validity of its approach one iota.


As a sidenote about the blocklisting: without signing being required, 
that's the only thing that could actually be done at that time. I mean, 
that or close off submissions for all non-AMO-listed frontloaded 
add-ons, which presumably would have made you (and many other people) 
even more angry. I wasn't involved in the decision, but I don't think it 
is "absurd", or that your calling attention to it (in your blogpost and 
elsewhere) was anything but sensationalizing the issue.



[Dan] says stuff like "And
it's just depressing that the entire Mozilla 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."

which basically boils down to an ad-hominem on Mozilla and an indictment
of "the system" and signing and the add-ons space generally, when
really, all we're talking about right now is how/whether to review
non-AMO-distributed add-ons before signing them. Dan acknowledges
elsewhere in his post that signing has other benefits, but the polemic
tone sure makes it seem like the entire plan we have here is rubbish
from start to finish.


It's the people defending automated scanning as a meaningful
deterrentagainst malware that are failing to make a distinction between 
different

parts of the system, not me.

I quoted you in the paragraph above this statement of yours. It is a 
matter of English spelling and grammar that your phrasing condemns all 
of the signing and review changes. Stop blame-shifting.



There's been a general trend there that Dan sees our attempts to try to
do something in that space as a one-way street where Mozilla should
basically make sure that all add-ons that used to work and weren't
distributed through AMO should not be disrupted, and we have been saying
that it's hard to improve user experience here if there are 0
restrictions, and so "something's gotta give". Dan wants a system where
he can (grudgingly) submit his add-on to AMO, and AMO gives it back to
him signed (ideally automatically via APIs) and nobody from Mozilla
(human or otherwise) reviews his code or tells him how to do stuff.


Read my post.


I read it before posting, so please don't insinuate I did not.


I'm not calling for no signing. I'm not calling for no

restrictions. I'm not calling for no review.

You're asking us to remove every bit of the automated review that 
prevents you from publishing zotero automatically without a blocking 
human review of your codebase.


I don't know how many of those bits there are (ie which bits are 
currently getting you dropped into the manual review queue), and how 
much would be left, and you have not specified this. If there were just 
a few, I assume you would simply have argued against those specific 
rules because that would have been a simpler change to make and convince 
people of, so I believe the conclusion I drew is reasonable.


In any case, if we left something of the automated review in, chances 
are Zotero would just run into the same thing in a future update where 
you added some more code that ran into the bit that wasn't problematic 
before, right?



I'm calling for changing

Re: Dan Stillman's concerns about Extension Signing

[Dan Stillman]

On 11/28/15 2:06 AM, Gavin Sharp wrote:

The assumption that the validator must catch all malicious code for add-on signing to be 
beneficial is incorrect, and seems to be what's fueling most of this thread. Validation 
being a prerequisite for automatic signing is not primarily a security measure, but 
rather just a way of eliminating "obvious" problems (security-related or 
otherwise) from installed and enabled add-ons generally. With add-on singing fully 
implemented, if (when) malicious add-ons get automatically signed, you'll have several 
more effective tools to deal with them, compared to the status quo.


Gavin, an "assumption that the validator must catch all malicious code 
for add-on signing to be beneficial" is not fueling any part of this 
thread. Based on this comment, it sounds like you haven't read either my 
original post [1] or my post to this list from a few hours ago [2]. It 
would be helpful if you would do so before trying to engage in this 
discussion.


Again, I'm not objecting to signing, automated review, or manual review 
on their own — I explicitly explain their benefits in my original post — 
but the pointlessly disruptive way they are currently implemented, which 
stems from faulty assumptions about the capabilities of the automated 
scanner.


[1] 
http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
[2] 
https://groups.google.com/d/msg/mozilla.dev.platform/AGW3-zSBjl8/iOZ-kYSmCQAJ

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Eric Rescorla]

On Fri, Nov 27, 2015 at 11:06 PM, Gavin Sharp  wrote:

> The assumption that the validator must catch all malicious code for add-on
> signing to be beneficial is incorrect, and seems to be what's fueling most
> of this thread.
>

I'm not sure how you got that out of my comments, since I explicitly said
the
opposite:"If we're trying to make it easier for authors to comply with our
policies (and avoid writing problematic add-ons), then a validator seems
reasonable"


Validation being a prerequisite for automatic signing is not primarily a
> security measure, but rather just a way of eliminating "obvious" problems
> (security-related or otherwise) from installed and enabled add-ons
> generally.
>

Sure, but the argument for it being a *hard* requirement is primarily a
security
one, and that's the one that falls afoul of the threat model point I made
below.



> With add-on singing fully implemented, if (when) malicious add-ons get
> automatically signed, you'll have several more effective tools to deal with
> them, compared to the status quo.
>

Yes.

-Ekr





> Gavin
>
> On Nov 27, 2015, at 8:49 PM, Eric Rescorla  wrote:
>
>
>
> On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari 
> wrote:
>
>> On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp 
>> wrote:
>>
>> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham 
>> wrote:
>> > > But the thing is, members of our security group are now piling into
>> the
>> > > bug pointing out that trying to find malicious JS code by static code
>> > > review is literally _impossible_ (and perhaps hinting that they'd have
>> > > said so much earlier if someone had asked them).
>> >
>> > No, that's not right. There's an important distinction between
>> > "finding malicious JS code" and "finding _all_ malicious JS code". The
>> > latter is impossible, but the former isn't.
>> >
>>
>> Note that malicious code here might look like this:
>>
>>   console.log("success");
>>
>> It's impossible to tell by looking at the code whether that line prints a
>> success message on the console, or something entirely different, such as
>> running calc.exe.
>>
>> A better framing for the problem is "finding some arbitrary instances of
>> malicious JS code" vs "finding malicious JS code".  My point in the bug
>> and
>> in the discussions prior to that was that a static checker can only do the
>> former, and as such, if the goal of the validator is finding malicious
>> code, its effectiveness is bound to be a lint tool at best.
>
>
> Indeed.  And if the validator is publicly accessible, let alone has public
> source code, it's likely to be straightforward for authors of malicious
> code to evade the validator. All they need to do is run their code
> through the validator, see what errors it spits out, and modify the
> code until it no longer spits out errors.
>
> Again, this goes back to threat model. If we're trying to make it easier
> for authors to comply with our policies (and avoid writing problematic
> add-ons), then a validator seems reasonable. However, if we're trying
> to prevent authors of malicious add-ons from getting their add-ons
> through, that seems much more questionable, for the reasons listed above.
> However, once we accept that we can't stop authors who are trying
> to evade detection, then treating it as a linter and allowing authors
> to override it seems a lot more sensible.
>
> -Ekr
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Eric Rescorla]

On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch 
wrote:

> On 27/11/2015 23:46, dstill...@zotero.org wrote:
>
>> The issue here is that this new system -- specifically, an automated
>> scanner sending extensions to manual review -- has been defended by
>> Jorge's saying, from March when I first brought this up until
>> yesterday on the hardening bug [1], that he believes the scanner can
>> "block the majority of malware".
>>
>
> Funny how you omit part of the quote you've listed elsewhere, namely:
> "block the majority of malware, but it will never be perfect".
>
> You assert the majority of malware will be 'smarter' than the validator
> expects (possibly after initial rejection) and bypass it. Jorge asserts,
> from years of experience, that malware authors are lazy and the validator
> has already been helpful, in conjunction with manual review.


Did Jorge in fact assert that that as a matter of fact or as a matter of
opinion?
Maybe I missed it.

This seems like an empirical question. how many pieces of obvious malware
(in the sense that once the functionality is found it's clearly malicious
code
as opposed to a mistake, not in the sense that it's easy to find the
functionality)
have been found by the review process? How many pieces of obvious malware
(in the sense above) have passed the review process or otherwise been
found in the wild?

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gavin Sharp]

I wasn't suggesting that you had made that incorrect assumption.

Gavin

On Sat, Nov 28, 2015 at 10:31 AM, Eric Rescorla  wrote:

> On Fri, Nov 27, 2015 at 11:06 PM, Gavin Sharp 
> wrote:
>
>> The assumption that the validator must catch all malicious code for
>> add-on signing to be beneficial is incorrect, and seems to be what's
>> fueling most of this thread.
>>
>
> I'm not sure how you got that out of my comments, since I explicitly said
> the
> opposite:"If we're trying to make it easier for authors to comply with our
> policies (and avoid writing problematic add-ons), then a validator seems
> reasonable"
>
>
> Validation being a prerequisite for automatic signing is not primarily a
>> security measure, but rather just a way of eliminating "obvious" problems
>> (security-related or otherwise) from installed and enabled add-ons
>> generally.
>>
>
> Sure, but the argument for it being a *hard* requirement is primarily a
> security
> one, and that's the one that falls afoul of the threat model point I made
> below.
>
>
>
>> With add-on singing fully implemented, if (when) malicious add-ons get
>> automatically signed, you'll have several more effective tools to deal with
>> them, compared to the status quo.
>>
>
> Yes.
>
> -Ekr
>
>
>
>
>
>> Gavin
>>
>> On Nov 27, 2015, at 8:49 PM, Eric Rescorla  wrote:
>>
>>
>>
>> On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari 
>> wrote:
>>
>>> On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp 
>>> wrote:
>>>
>>> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham 
>>> wrote:
>>> > > But the thing is, members of our security group are now piling into
>>> the
>>> > > bug pointing out that trying to find malicious JS code by static code
>>> > > review is literally _impossible_ (and perhaps hinting that they'd
>>> have
>>> > > said so much earlier if someone had asked them).
>>> >
>>> > No, that's not right. There's an important distinction between
>>> > "finding malicious JS code" and "finding _all_ malicious JS code". The
>>> > latter is impossible, but the former isn't.
>>> >
>>>
>>> Note that malicious code here might look like this:
>>>
>>>   console.log("success");
>>>
>>> It's impossible to tell by looking at the code whether that line prints a
>>> success message on the console, or something entirely different, such as
>>> running calc.exe.
>>>
>>> A better framing for the problem is "finding some arbitrary instances of
>>> malicious JS code" vs "finding malicious JS code".  My point in the bug
>>> and
>>> in the discussions prior to that was that a static checker can only do
>>> the
>>> former, and as such, if the goal of the validator is finding malicious
>>> code, its effectiveness is bound to be a lint tool at best.
>>
>>
>> Indeed.  And if the validator is publicly accessible, let alone has public
>> source code, it's likely to be straightforward for authors of malicious
>> code to evade the validator. All they need to do is run their code
>> through the validator, see what errors it spits out, and modify the
>> code until it no longer spits out errors.
>>
>> Again, this goes back to threat model. If we're trying to make it easier
>> for authors to comply with our policies (and avoid writing problematic
>> add-ons), then a validator seems reasonable. However, if we're trying
>> to prevent authors of malicious add-ons from getting their add-ons
>> through, that seems much more questionable, for the reasons listed above.
>> However, once we accept that we can't stop authors who are trying
>> to evade detection, then treating it as a linter and allowing authors
>> to override it seems a lot more sensible.
>>
>> -Ekr
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Eric Rescorla]

On Sat, Nov 28, 2015 at 11:30 AM, Kartikaya Gupta 
wrote:

> So it seems to me that people are actually in general agreement about
> what the validator can and cannot do, but have different evaluations
> of the cost-benefit tradeoff.
>
> On the one hand we have the camp (let's say camp A) that believes the
> validator provides negligible actual benefit, because it is trival to
> bypass, but at the same time provides a huge cost to add-on
> developers. And on the other hand we have the camp ("camp B") that
> believes the validator provides some non-negligible benefit, even
> though it may significantly increase the cost to add-on developers.
>
> From what I have been told from multiple people, Mozilla does have
> actual data on the type and number of malicious add-ons in the wild,
> and it cannot be published. I don't really like this since it goes
> against openness and whatnot, but I can accept that there are
> legitimate reasons for not publishing this data.
>

It may be the case that access to the raw data needs to be restricted
(though it's not clear to me why) but I don't see why the basic facts
I asked for need to be restricted, and those are all that is needed
to evaluate the question at hand.

-Ekr



>
> On Sat, Nov 28, 2015 at 10:35 AM, Eric Rescorla  wrote:
> > On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch <
> gijskruitbo...@gmail.com>
> > wrote:
> >
> >> On 27/11/2015 23:46, dstill...@zotero.org wrote:
> >>
> >>> The issue here is that this new system -- specifically, an automated
> >>> scanner sending extensions to manual review -- has been defended by
> >>> Jorge's saying, from March when I first brought this up until
> >>> yesterday on the hardening bug [1], that he believes the scanner can
> >>> "block the majority of malware".
> >>>
> >>
> >> Funny how you omit part of the quote you've listed elsewhere, namely:
> >> "block the majority of malware, but it will never be perfect".
> >>
> >> You assert the majority of malware will be 'smarter' than the validator
> >> expects (possibly after initial rejection) and bypass it. Jorge asserts,
> >> from years of experience, that malware authors are lazy and the
> validator
> >> has already been helpful, in conjunction with manual review.
> >
> >
> > Did Jorge in fact assert that that as a matter of fact or as a matter of
> > opinion?
> > Maybe I missed it.
> >
> > This seems like an empirical question. how many pieces of obvious malware
> > (in the sense that once the functionality is found it's clearly malicious
> > code
> > as opposed to a mistake, not in the sense that it's easy to find the
> > functionality)
> > have been found by the review process? How many pieces of obvious malware
> > (in the sense above) have passed the review process or otherwise been
> > found in the wild?
> >
> > -Ekr
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Eric Rescorla]

How odd that your e-mail was in response to mine, then.

-Ekr


On Sat, Nov 28, 2015 at 11:34 AM, Gavin Sharp  wrote:

> I wasn't suggesting that you had made that incorrect assumption.
>
> Gavin
>
> On Sat, Nov 28, 2015 at 10:31 AM, Eric Rescorla  wrote:
>
>> On Fri, Nov 27, 2015 at 11:06 PM, Gavin Sharp 
>> wrote:
>>
>>> The assumption that the validator must catch all malicious code for
>>> add-on signing to be beneficial is incorrect, and seems to be what's
>>> fueling most of this thread.
>>>
>>
>> I'm not sure how you got that out of my comments, since I explicitly said
>> the
>> opposite:"If we're trying to make it easier for authors to comply with
>> our policies (and avoid writing problematic add-ons), then a validator
>> seems reasonable"
>>
>>
>> Validation being a prerequisite for automatic signing is not primarily a
>>> security measure, but rather just a way of eliminating "obvious" problems
>>> (security-related or otherwise) from installed and enabled add-ons
>>> generally.
>>>
>>
>> Sure, but the argument for it being a *hard* requirement is primarily a
>> security
>> one, and that's the one that falls afoul of the threat model point I made
>> below.
>>
>>
>>
>>> With add-on singing fully implemented, if (when) malicious add-ons get
>>> automatically signed, you'll have several more effective tools to deal with
>>> them, compared to the status quo.
>>>
>>
>> Yes.
>>
>> -Ekr
>>
>>
>>
>>
>>
>>> Gavin
>>>
>>> On Nov 27, 2015, at 8:49 PM, Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari 
>>> wrote:
>>>
 On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp 
 wrote:

 > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham 
 wrote:
 > > But the thing is, members of our security group are now piling into
 the
 > > bug pointing out that trying to find malicious JS code by static
 code
 > > review is literally _impossible_ (and perhaps hinting that they'd
 have
 > > said so much earlier if someone had asked them).
 >
 > No, that's not right. There's an important distinction between
 > "finding malicious JS code" and "finding _all_ malicious JS code". The
 > latter is impossible, but the former isn't.
 >

 Note that malicious code here might look like this:

   console.log("success");

 It's impossible to tell by looking at the code whether that line prints
 a
 success message on the console, or something entirely different, such as
 running calc.exe.

 A better framing for the problem is "finding some arbitrary instances of
 malicious JS code" vs "finding malicious JS code".  My point in the bug
 and
 in the discussions prior to that was that a static checker can only do
 the
 former, and as such, if the goal of the validator is finding malicious
 code, its effectiveness is bound to be a lint tool at best.
>>>
>>>
>>> Indeed.  And if the validator is publicly accessible, let alone has
>>> public
>>> source code, it's likely to be straightforward for authors of malicious
>>> code to evade the validator. All they need to do is run their code
>>> through the validator, see what errors it spits out, and modify the
>>> code until it no longer spits out errors.
>>>
>>> Again, this goes back to threat model. If we're trying to make it easier
>>> for authors to comply with our policies (and avoid writing problematic
>>> add-ons), then a validator seems reasonable. However, if we're trying
>>> to prevent authors of malicious add-ons from getting their add-ons
>>> through, that seems much more questionable, for the reasons listed above.
>>> However, once we accept that we can't stop authors who are trying
>>> to evade detection, then treating it as a linter and allowing authors
>>> to override it seems a lot more sensible.
>>>
>>> -Ekr
>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Dan Stillman]

On 11/28/15 5:06 AM, Gijs Kruitbosch wrote:

On 27/11/2015 23:46, dstill...@zotero.org wrote:

The issue here is that this new system -- specifically, an automated
scanner sending extensions to manual review -- has been defended by
Jorge's saying, from March when I first brought this up until
yesterday on the hardening bug [1], that he believes the scanner can
"block the majority of malware".


Funny how you omit part of the quote you've listed elsewhere, namely: 
"block the majority of malware, but it will never be perfect".


You assert the majority of malware will be 'smarter' than the 
validator expects (possibly after initial rejection) and bypass it. 
Jorge asserts, from years of experience, that malware authors are lazy 
and the validator has already been helpful, in conjunction with manual 
review. It's not helpful to say that what Jorge is saying is "not 
true" - you mean different things when you say "the majority of malware".


I've addressed this repeatedly. In my view, saying "it will never be 
perfect" is a misleading statement that betrays a misunderstanding of 
the technical issues. If the system is so trivial to bypass that anyone 
with a basic grasp of JavaScript would have to essentially volunteer to 
be manually reviewed, the system cannot block malware. Again, malware 
that wants to be detected isn't really malware.


The idea that a malware author is going to say, "Oh, man, I was all set 
to release this malware and make lots of money, but then the scanner 
flagged 'nsIProcess', and 'n'.replace() + 'sIProcess' is just too much 
effort, so I guess I'll just give up and go attack users some other way" 
is totally absurd. You're really going to defend that claim? You can't 
just say, "OK, I guess that argument doesn't really make sense, so maybe 
we should reconsider what we're actually trying to block"?



Jorge has been saying he believes the scanner can block most malware

because he genuinely doesn't understand the technical issues here, as
his statements (and his absurd blocklisting of the PoC) make clear. It's
hard not to make this sound like a personal attack,

This is what's so offensive. It's hard to make this not sound like a 
personal attack because it *is* a personal attack. What's more, 
Jorge's competence or otherwise is irrelevant to the discussion. Your 
insistently bringing it up and your condescending attitude towards 
Jorge and other Mozilla folks is offensive, unhelpful, and not 
constructive in addressing the actual issue at hand. If we were some 
nameless corporation you wouldn't even know the name of the person 
responsible for the add-ons system, but that wouldn't change its 
quality or the validity of its approach one iota.


If the person who's been defending this system for the last year isn't 
aware of the technical issues and has been making statements that aren't 
borne out by what's technically possible, and I point that out, that's 
not a personal attack. It's a relevant data point in understanding how a 
bad policy might have been put into place and defended against 
criticism. If that person has been the one refusing to implement a 
whitelist for extensions like Zotero without understanding that, because 
of what I've demonstrated, whitelisted extensions couldn't do anything 
that unlisted extensions couldn't, that's relevant to the issue.


Jorge admitted he doesn't understand the PoC, so that's not really up 
for debate: "I don't know if we will be able to detect the particular 
workarounds implemented in this bypass add-on; I'll leave that to the 
dev team to determine and file individual dependencies." [1]


As a sidenote about the blocklisting: without signing being required, 
that's the only thing that could actually be done at that time. I 
mean, that or close off submissions for all non-AMO-listed frontloaded 
add-ons, which presumably would have made you (and many other people) 
even more angry. I wasn't involved in the decision, but I don't think 
it is "absurd", or that your calling attention to it (in your blogpost 
and elsewhere) was anything but sensationalizing the issue.


What? The only thing that could have been done? To accomplish what? It 
was a proof of concept, with non-malicious example code hardcoded to 
localhost. And the issues in it can't, by definition, be blocked by the 
validator, which Jorge didn't understand (as he said himself on the 
hardening bug). No one who understood what the PoC was or what it 
implied would have blocklisted it, because it makes literally no sense 
to do so.



[Dan] says stuff like "And
it's just depressing that the entire Mozilla 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."

which basically boils down to an ad-hominem on Mozilla and an 
indictment

of "the system" and signing and the add-ons space generally, when
really, all we're 

Re: Dan Stillman's concerns about Extension Signing

[Dan Stillman]

On 11/28/15 2:30 PM, Kartikaya Gupta wrote:

So it seems to me that people are actually in general agreement about
what the validator can and cannot do, but have different evaluations
of the cost-benefit tradeoff.

On the one hand we have the camp (let's say camp A) that believes the
validator provides negligible actual benefit, because it is trival to
bypass, but at the same time provides a huge cost to add-on
developers. And on the other hand we have the camp ("camp B") that
believes the validator provides some non-negligible benefit, even
though it may significantly increase the cost to add-on developers.

 From what I have been told from multiple people, Mozilla does have
actual data on the type and number of malicious add-ons in the wild,
and it cannot be published. I don't really like this since it goes
against openness and whatnot, but I can accept that there are
legitimate reasons for not publishing this data. So the question is -
do the people in camp A or the people in camp B have access to this
data? I would argue that whoever has access to the data is in a better
position to make the right call with respect to the cost-benefit
tradeoff, and everybody else should defer to them. If people in both
camps have access to the data, then clearly they have different
interpretations of the data and they should discuss it further.
Presumably they know who they are.


Unfortunately I think there is still some confusion about the 
implications of my PoC [1].


But putting that aside, I don't see how historical data is valid, given 
how trivial the bypass is. Since this sort of obfuscation hasn't been 
necessary, there's been no reason for it to be done. But that doesn't 
make it any less trivial, or require malware authors to be any less 
"lazy" to get their code signed.


Certainly arguments that have been made against whitelisting over the 
last few months don't hold up to scrutiny in light of the PoC, unless 
you're willing to argue that someone who compromised Zotero's servers, 
got into our VCS, got code past our review process, purchased Zotero 
from a large research university to turn it into malware, etc., would 
also be unable to dynamically generate a property name.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c26
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Kartikaya Gupta]

So it seems to me that people are actually in general agreement about
what the validator can and cannot do, but have different evaluations
of the cost-benefit tradeoff.

On the one hand we have the camp (let's say camp A) that believes the
validator provides negligible actual benefit, because it is trival to
bypass, but at the same time provides a huge cost to add-on
developers. And on the other hand we have the camp ("camp B") that
believes the validator provides some non-negligible benefit, even
though it may significantly increase the cost to add-on developers.

>From what I have been told from multiple people, Mozilla does have
actual data on the type and number of malicious add-ons in the wild,
and it cannot be published. I don't really like this since it goes
against openness and whatnot, but I can accept that there are
legitimate reasons for not publishing this data. So the question is -
do the people in camp A or the people in camp B have access to this
data? I would argue that whoever has access to the data is in a better
position to make the right call with respect to the cost-benefit
tradeoff, and everybody else should defer to them. If people in both
camps have access to the data, then clearly they have different
interpretations of the data and they should discuss it further.
Presumably they know who they are.

kats


On Sat, Nov 28, 2015 at 10:35 AM, Eric Rescorla  wrote:
> On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch 
> wrote:
>
>> On 27/11/2015 23:46, dstill...@zotero.org wrote:
>>
>>> The issue here is that this new system -- specifically, an automated
>>> scanner sending extensions to manual review -- has been defended by
>>> Jorge's saying, from March when I first brought this up until
>>> yesterday on the hardening bug [1], that he believes the scanner can
>>> "block the majority of malware".
>>>
>>
>> Funny how you omit part of the quote you've listed elsewhere, namely:
>> "block the majority of malware, but it will never be perfect".
>>
>> You assert the majority of malware will be 'smarter' than the validator
>> expects (possibly after initial rejection) and bypass it. Jorge asserts,
>> from years of experience, that malware authors are lazy and the validator
>> has already been helpful, in conjunction with manual review.
>
>
> Did Jorge in fact assert that that as a matter of fact or as a matter of
> opinion?
> Maybe I missed it.
>
> This seems like an empirical question. how many pieces of obvious malware
> (in the sense that once the functionality is found it's clearly malicious
> code
> as opposed to a mistake, not in the sense that it's easy to find the
> functionality)
> have been found by the review process? How many pieces of obvious malware
> (in the sense above) have passed the review process or otherwise been
> found in the wild?
>
> -Ekr
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Mike Hoye]

On 2015-11-28 2:40 PM, Eric Rescorla wrote:

How odd that your e-mail was in response to mine, then.


Thanks, super helpful, really moved the discussion forward, high five.

To Ehsan's point that "malicious code here might look like this: 
console.log("success"); [and] It's impossible to tell by looking at the 
code whether that line prints a success message on the console, or 
something entirely different, such as running calc.exe." - that's true, 
but it also looks a lot like the sort of problem antivirus vendors have 
been dealing with for a long time now. Turing completeness is a thing, 
the halting problem exists and monsters are real, sure, but that doesn't 
mean having antivirus software is a waste of time that solves no 
problems and protects nobody.


One key claim Stillman made, that  " A system that takes five minutes to 
circumvent does not “raise the bar” in any real way", is perhaps true in 
an academic sense, but not in a practical one. We know a lot more than 
we did a decade ago about the nature of malicious online actors, and one 
of the things we know for a fact is the great majority of malicious 
actors on the 'net are - precisely as Jorge asserts - lazy, and that 
minor speedbumps - sometimes as little as a couple of extra clicks - are 
an effective barrier to people who are doing whatever it is they're 
about to do because they're bored and it's easy. And that's most of them.


Any semicompetent locksmith can walk through your locked front door 
without breaking stride, but you lock it anyway because keeping out 
badly-raised teenagers is not "security theater", it's sensible, 
cost-effective risk management.


- mhoye

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Eric Rescorla]

On Sat, Nov 28, 2015 at 5:28 PM, Mike Hoye  wrote:

> On 2015-11-28 2:40 PM, Eric Rescorla wrote:
>
>> How odd that your e-mail was in response to mine, then.
>>
>> Thanks, super helpful, really moved the discussion forward, high five.


Glad I could help.


To Ehsan's point that "malicious code here might look like this:
> console.log("success"); [and] It's impossible to tell by looking at the
> code whether that line prints a success message on the console, or
> something entirely different, such as running calc.exe." - that's true, but
> it also looks a lot like the sort of problem antivirus vendors have been
> dealing with for a long time now. Turing completeness is a thing, the
> halting problem exists and monsters are real, sure, but that doesn't mean
> having antivirus software is a waste of time that solves no problems and
> protects nobody.
>

Interesting you should mention antivirus. One of the advantages that
antivirus
manufacturers have is that they are able to deploy signatures for malware
which
is already in the wild, so that they get to update their virus signatures
after the
malware is already written, so they know that the fielded malware will be
detectable.
And even then, it's well-known that malware authors test their prototype
malware against existing antivirus packages, which is part of the reason for
the relatively low effectiveness of commercial antivirus packages against
novel malware [0]. The system we are discussing here is quite similar,
except
much easier for the attacker because there is only one scanner they need
to defeat and they can download it and try it for themselves.



> One key claim Stillman made, that  " A system that takes five minutes to
> circumvent does not “raise the bar” in any real way", is perhaps true in an
> academic sense, but not in a practical one. We know a lot more than we did
> a decade ago about the nature of malicious online actors, and one of the
> things we know for a fact is the great majority of malicious actors on the
> 'net are - precisely as Jorge asserts - lazy, and that minor speedbumps -
> sometimes as little as a couple of extra clicks - are an effective barrier
> to people who are doing whatever it is they're about to do because they're
> bored and it's easy. And that's most of them.
>

This might be true or it might not. I'd be interested in seeing some
evidence that it is
in fact true, specifically, that the scanner catches a lot of malware, as
opposed to
just broken-ware. Do you have such evidence?

-Ekr


[0]
http://krebsonsecurity.com/2010/04/virus-scanners-for-virus-authors-part-ii/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Dan Stillman]

On 11/28/15 8:28 PM, Mike Hoye wrote:
To Ehsan's point that "malicious code here might look like this: 
console.log("success"); [and] It's impossible to tell by looking at 
the code whether that line prints a success message on the console, or 
something entirely different, such as running calc.exe." - that's 
true, but it also looks a lot like the sort of problem antivirus 
vendors have been dealing with for a long time now. Turing 
completeness is a thing, the halting problem exists and monsters are 
real, sure, but that doesn't mean having antivirus software is a waste 
of time that solves no problems and protects nobody.


You can block known malware signatures with the scanner if you think 
that's a good use of time. But that doesn't require blocking valid APIs 
and patterns that have legitimate uses. That's what we're discussing 
here. AV software doesn't result in long delays in legitimate software 
updates so that AV vendors can manually review software.


One key claim Stillman made, that  " A system that takes five minutes 
to circumvent does not “raise the bar” in any real way", is perhaps 
true in an academic sense, but not in a practical one. We know a lot 
more than we did a decade ago about the nature of malicious online 
actors, and one of the things we know for a fact is the great majority 
of malicious actors on the 'net are - precisely as Jorge asserts - 
lazy, and that minor speedbumps - sometimes as little as a couple of 
extra clicks - are an effective barrier to people who are doing 
whatever it is they're about to do because they're bored and it's 
easy. And that's most of them.


Any semicompetent locksmith can walk through your locked front door 
without breaking stride, but you lock it anyway because keeping out 
badly-raised teenagers is not "security theater", it's sensible, 
cost-effective risk management.


I just don't see how this argument makes any sense.

First, we're not talking about locksmiths. We're talking about people 
who know how to turn doorknobs. Any JS developer is able to do this sort 
of obfuscation in a minute or two.


But here's the point: just setting up the skeleton extension for my PoC 
took longer than writing the examples. Actually writing any malicious 
code certainly would take longer. And surely if they're as lazy as you 
suggest, they're not going to bother creating a dummy extension, 
creating an account, submitting it for an initial manual review (as I 
suggest in my post), waiting days for approval, and adding in the 
malicious code, only to then decide to go eat some Cheez-Its instead of 
spending another minute modifying the code to pass the automated 
scanner. Do you honestly believe that?


Even if you do — which seems crazy to me — the relevant question is 
whether it's worth delaying legitimate extension updates for days at a 
time and possibly driving developers away from the platform (as in the 
case of Zotero) in the name of blocking that incomprehensible level of 
laziness. Do you think it is?


And even if we somehow don't agree on any of that, surely we can agree 
that someone who bought off or compromised a legitimate extension 
developer (or was the developer to begin with) would be willing to put 
in that extra minute?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gavin Sharp]

On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham  wrote:
> But the thing is, members of our security group are now piling into the
> bug pointing out that trying to find malicious JS code by static code
> review is literally _impossible_ (and perhaps hinting that they'd have
> said so much earlier if someone had asked them).

No, that's not right. There's an important distinction between
"finding malicious JS code" and "finding _all_ malicious JS code". The
latter is impossible, but the former isn't.

Proving "the validator won't catch everything" isn't particularly
relevant when it isn't intended to, in the overall add-on signing
system design.

Gavin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gervase Markham]

On 26/11/15 17:13, Mike Hoye wrote:
> Stillman wrote some new code and put it through a process meant to catch
> problems in old code, and it passed. That's unfortunate, but does it
> really surprise anyone that security is an evolving process? That it
> might be be full of hard tradeoffs? There is a _huge_gap_ between "new
> code can defeat old security measures" and "therefore all the old
> security measures are useless". 

But the thing is, members of our security group are now piling into the
bug pointing out that trying to find malicious JS code by static code
review is literally _impossible_ (and perhaps hinting that they'd have
said so much earlier if someone had asked them).

You can evolve your process all you like, but if something is
impossible, it's impossible. And not only that, but attempting it seems
to be causing significant collateral damage.

> It's an even bigger step from there to
> the implication that people working on this either haven't thought about
> it already, or just don't care.

I agree with that.

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gijs Kruitbosch]

On 27/11/2015 12:16, Gervase Markham wrote:

On 26/11/15 17:13, Mike Hoye wrote:

Stillman wrote some new code and put it through a process meant to catch
problems in old code, and it passed. That's unfortunate, but does it
really surprise anyone that security is an evolving process? That it
might be be full of hard tradeoffs? There is a _huge_gap_ between "new
code can defeat old security measures" and "therefore all the old
security measures are useless".


But the thing is, members of our security group are now piling into the
bug pointing out that trying to find malicious JS code by static code
review is literally _impossible_ (and perhaps hinting that they'd have
said so much earlier if someone had asked them).


That's not what they're saying. They're saying it is impossible to 
guarantee with static analysis that code is not malicious. Nobody 
disputes that, and nobody did before they started saying it, either. The 
distinction is that the static code review finds *some* malicious JS 
code. Dan's charge is that this is not useful because malware authors 
will realize this (we tell them that their add-on got rejected and why!) 
and try to bypass that review until they manage it.


This entire discussion is pretty orthogonal to the fact that we're 
signing add-ons and the issues that Till and Thomas were talking about 
anyway (which was basically: now add-ons need to be reviewed to be 
signed and that review takes a long time, and that disrupts users and 
add-on developers).



And not only that, but attempting it seems
to be causing significant collateral damage.


This is the interesting bit. The reason Dan is bringing this up is not 
his concern for users' safety but the fact that the same automated 
scanning is flagging things in his add-on that he claims aren't "real" 
issues, this causes him to land in the "manual review" queue, and that 
takes time.


To my mind, the logical conclusion of Dan's post is that he should want 
all add-ons to be manually reviewed all the time. He claims that if 
static analysis does not guarantee benign code, it is not worth having 
it at all (something which I would dispute (see distinction drawn 
above), but let's stick with it for now).


The reason we're drawing different conclusions is that I believe we 
still want to do something about the issues caused by frontloaded 
add-ons not distributed through AMO, and so we will need to do some kind 
of review, and if we get rid of the static analysis, the logical thing 
to do would be to use manual review.


Of course, having to manually review all the add-ons is going to cause 
even more delays, and is therefore not in Dan's interest, so instead he 
posits that we should just drop all our attempts to control issues 
caused by frontloaded add-ons not distributed through AMO.


The interesting thing is that Dan is nominally talking about how we're 
trying to moderate quality and safety in a space where we haven't before 
(ie add-ons not distributed through AMO), but then says stuff like "And 
it’s just depressing that the entire Mozilla 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."


which basically boils down to an ad-hominem on Mozilla and an indictment 
of "the system" and signing and the add-ons space generally, when 
really, all we're talking about right now is how/whether to review 
non-AMO-distributed add-ons before signing them. Dan acknowledges 
elsewhere in his post that signing has other benefits, but the polemic 
tone sure makes it seem like the entire plan we have here is rubbish 
from start to finish.


There's been a general trend there that Dan sees our attempts to try to 
do something in that space as a one-way street where Mozilla should 
basically make sure that all add-ons that used to work and weren't 
distributed through AMO should not be disrupted, and we have been saying 
that it's hard to improve user experience here if there are 0 
restrictions, and so "something's gotta give". Dan wants a system where 
he can (grudgingly) submit his add-on to AMO, and AMO gives it back to 
him signed (ideally automatically via APIs) and nobody from Mozilla 
(human or otherwise) reviews his code or tells him how to do stuff. And 
we're trying to improve the state of non-AMO add-ons. Those two desires 
are fundamentally very hard to reconcile. And that has very little to do 
with whether or not static analysis can guarantee you non-malicious code 
or not.


~ Gijs

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gijs Kruitbosch]

On 27/11/2015 13:41, Frederik Braun wrote:

On 27.11.2015 13:16, Gervase Markham wrote:

On 26/11/15 17:13, Mike Hoye wrote:

Stillman wrote some new code and put it through a process meant to catch
problems in old code, and it passed. That's unfortunate, but does it
really surprise anyone that security is an evolving process? That it
might be be full of hard tradeoffs? There is a _huge_gap_ between "new
code can defeat old security measures" and "therefore all the old
security measures are useless".


But the thing is, members of our security group are now piling into the
bug pointing out that trying to find malicious JS code by static code
review is literally _impossible_ (and perhaps hinting that they'd have
said so much earlier if someone had asked them).

You can evolve your process all you like, but if something is
impossible, it's impossible. And not only that, but attempting it seems
to be causing significant collateral damage.



We can detect obfuscation and disallow it, though. It's not "all is
lost", but "impossible to be 100% exact, if we allow arbitrary
JavaScript". I think we already disallow certain language features (e.g.
eval?).


I don't think we currently disallow eval() on the Firefox side, and I 
think disallowing both eval() and Function() and friends might break a 
lot of add-ons. AMO discourages its use, but I don't know that there are 
literally 0 cases of it, and the use of eval() can be obfuscated itself...


That and we have the subscript loader, Cu.import and numerous other ways 
of running script. If necessary as an add-on you could implement your 
own protocol handler for strings and load scripts that way. It's pretty 
hard to nail this down for XUL add-ons, and, to a lesser degree, jetpack 
- yet another reason for Web Extensions.


It's actually an interesting idea, IMO, to see if we could just remove 
access to the Function constructor and eval() in chrome compartments (ie 
not make them available on |window| or any other chrome global at all), 
and see how much stuff breaks. My guess is "quite a lot", but I've been 
wrong before - and of course, we could fix it...


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Thomas Zimmermann]

Hi

Am 26.11.2015 um 18:13 schrieb Mike Hoye:

> Stillman wrote some new code and put it through a process meant to
> catch problems in old code, and it passed. That's unfortunate, but
> does it really surprise anyone that security is an evolving process?
> That it might be be full of hard tradeoffs? There is a _huge_gap_
> between "new code can defeat old security measures" and "therefore all
> the old security measures are useless". It's an even bigger step from
> there to the implication that people working on this either haven't
> thought about it already, or just don't care.

I was trying to suggest a possible solution; nothing more and nothing
less. I didn't intend to imply that you or anyone else didn't know or
didn't care, and I especially didn't intend to insult anyone. I'm sorry
if my mail came across like this.

Best regards
Thomas

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Frederik Braun]

On 27.11.2015 13:16, Gervase Markham wrote:
> On 26/11/15 17:13, Mike Hoye wrote:
>> Stillman wrote some new code and put it through a process meant to catch
>> problems in old code, and it passed. That's unfortunate, but does it
>> really surprise anyone that security is an evolving process? That it
>> might be be full of hard tradeoffs? There is a _huge_gap_ between "new
>> code can defeat old security measures" and "therefore all the old
>> security measures are useless". 
> 
> But the thing is, members of our security group are now piling into the
> bug pointing out that trying to find malicious JS code by static code
> review is literally _impossible_ (and perhaps hinting that they'd have
> said so much earlier if someone had asked them).
> 
> You can evolve your process all you like, but if something is
> impossible, it's impossible. And not only that, but attempting it seems
> to be causing significant collateral damage.
> 

We can detect obfuscation and disallow it, though. It's not "all is
lost", but "impossible to be 100% exact, if we allow arbitrary
JavaScript". I think we already disallow certain language features (e.g.
eval?).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[dstillman]

On Friday, November 27, 2015 at 7:59:37 AM UTC-5, Gijs Kruitbosch wrote:
> On 27/11/2015 12:16, Gervase Markham wrote:
> > On 26/11/15 17:13, Mike Hoye wrote:
> >> Stillman wrote some new code and put it through a process meant to catch
> >> problems in old code, and it passed. That's unfortunate, but does it
> >> really surprise anyone that security is an evolving process? That it
> >> might be be full of hard tradeoffs? There is a _huge_gap_ between "new
> >> code can defeat old security measures" and "therefore all the old
> >> security measures are useless".
> >
> > But the thing is, members of our security group are now piling into the
> > bug pointing out that trying to find malicious JS code by static code
> > review is literally _impossible_ (and perhaps hinting that they'd have
> > said so much earlier if someone had asked them).
> 
> That's not what they're saying. They're saying it is impossible to 
> guarantee with static analysis that code is not malicious. Nobody 
> disputes that, and nobody did before they started saying it, either. The 
> distinction is that the static code review finds *some* malicious JS 
> code. Dan's charge is that this is not useful because malware authors 
> will realize this (we tell them that their add-on got rejected and why!) 
> and try to bypass that review until they manage it.

Repeatedly claiming (as a number of Mozilla folks have now done) that "nobody 
ever said we could detect all malicious code" isn't helpful. That's a strawman 
argument.

The issue here is that this new system -- specifically, an automated scanner 
sending extensions to manual review -- has been defended by Jorge's saying, 
from March when I first brought this up until yesterday on the hardening bug 
[1], that he believes the scanner can "block the majority of malware". That's 
simply not the case. The scanner cannot block even trivial attempts at 
obfuscation. That's what members of your security group are saying, and what my 
PoC demonstrates. You literally cannot block the sorts of examples in my PoC 
without blocking all extensions. (As I note on the hardening bug, the confusion 
here may be partly my fault. The examples in my PoC -- e.g., 'e'.replace() + 
'val' -- were meant to be somewhat humorous, but the point is just that you can 
bypass the scanner by generating a string, and it's provably impossible to 
figure out what those strings would be from static analysis.) 

The implication of this is that manual review would be strictly voluntary on 
the part of the extension developer, and so you would almost by definition be 
sending only legitimate developers to manual review. If malware wants to be 
detected, it's sort of by definition not malware.

Jorge has been saying he believes the scanner can block most malware because he 
genuinely doesn't understand the technical issues here, as his statements (and 
his absurd blocklisting of the PoC) make clear. It's hard not to make this 
sound like a personal attack, but that's really not my intention. Throughout 
this process, Jorge should have had the support of Mozilla engineers who 
understand that the claims he's been making about the scanner are not possible. 
Some people are now attempting to defend him by saying "well we never said it 
could block all malware", but that's a misrepresentation of the disconnect here.

Even the developer of the validator, asking a month ago whether combating this 
sort of trivial obfuscation was possible (it's not, as he was told), said, 
"Without it the validator remains more an advisory/helpful tool than something 
we could use to automate security validation." [2]

> > And not only that, but attempting it seems
> > to be causing significant collateral damage.
> 
> This is the interesting bit. The reason Dan is bringing this up is not 
> his concern for users' safety but the fact that the same automated 
> scanning is flagging things in his add-on that he claims aren't "real" 
> issues, this causes him to land in the "manual review" queue, and that 
> takes time.

Zotero is flagged for manual review 1) because of our use of things like 
nsIProcess and js-ctypes and 2) because we have hundreds of thousands of lines 
of code, which both time out the validator (though presumably that could be 
fixed) and all but guarantee that there will be something in every update that 
is flagged, because the scanner blocks all sorts of highly ambiguous things.

And yes, in our case the things it is flagging are indeed not "real" issues, as 
AMO editors have acknowledged in every review we've ever received. An AMO 
review has never identified a legitimate security issue in Zotero -- if they 
had, 1) we would've been grateful and 2) they wouldn't have approved us.

The collateral damage here is legitimate developers and the users of their 
extensions, who are denied timely updates (including important bug fixes) based 
on a scanner that blocks legitimate extensions but that by definition cannot 
block anyone who 

Re: Dan Stillman's concerns about Extension Signing

[Ehsan Akhgari]

On 2015-11-27 8:41 AM, Frederik Braun wrote:

On 27.11.2015 13:16, Gervase Markham wrote:

On 26/11/15 17:13, Mike Hoye wrote:

Stillman wrote some new code and put it through a process meant to catch
problems in old code, and it passed. That's unfortunate, but does it
really surprise anyone that security is an evolving process? That it
might be be full of hard tradeoffs? There is a _huge_gap_ between "new
code can defeat old security measures" and "therefore all the old
security measures are useless".


But the thing is, members of our security group are now piling into the
bug pointing out that trying to find malicious JS code by static code
review is literally _impossible_ (and perhaps hinting that they'd have
said so much earlier if someone had asked them).

You can evolve your process all you like, but if something is
impossible, it's impossible. And not only that, but attempting it seems
to be causing significant collateral damage.



We can detect obfuscation and disallow it, though.


No, we unfortunately cannot do that.  That is really the same problem as 
detecting malicious add-ons by looking at the code which is impossible 
because of the previously mentioned reasons.


(Note that you may be thinking about obfuscations done by tools such as 
minifiers, but the interesting obfuscation here is deliberate ones done 
by an attacker trying to mislead a human or machine reviewing their code 
for maliciousness.)


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Eric Rescorla]

On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari 
wrote:

> On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp 
> wrote:
>
> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham 
> wrote:
> > > But the thing is, members of our security group are now piling into the
> > > bug pointing out that trying to find malicious JS code by static code
> > > review is literally _impossible_ (and perhaps hinting that they'd have
> > > said so much earlier if someone had asked them).
> >
> > No, that's not right. There's an important distinction between
> > "finding malicious JS code" and "finding _all_ malicious JS code". The
> > latter is impossible, but the former isn't.
> >
>
> Note that malicious code here might look like this:
>
>   console.log("success");
>
> It's impossible to tell by looking at the code whether that line prints a
> success message on the console, or something entirely different, such as
> running calc.exe.
>
> A better framing for the problem is "finding some arbitrary instances of
> malicious JS code" vs "finding malicious JS code".  My point in the bug and
> in the discussions prior to that was that a static checker can only do the
> former, and as such, if the goal of the validator is finding malicious
> code, its effectiveness is bound to be a lint tool at best.


Indeed.  And if the validator is publicly accessible, let alone has public
source code, it's likely to be straightforward for authors of malicious
code to evade the validator. All they need to do is run their code
through the validator, see what errors it spits out, and modify the
code until it no longer spits out errors.

Again, this goes back to threat model. If we're trying to make it easier
for authors to comply with our policies (and avoid writing problematic
add-ons), then a validator seems reasonable. However, if we're trying
to prevent authors of malicious add-ons from getting their add-ons
through, that seems much more questionable, for the reasons listed above.
However, once we accept that we can't stop authors who are trying
to evade detection, then treating it as a linter and allowing authors
to override it seems a lot more sensible.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Ehsan Akhgari]

On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp  wrote:

> On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham  wrote:
> > But the thing is, members of our security group are now piling into the
> > bug pointing out that trying to find malicious JS code by static code
> > review is literally _impossible_ (and perhaps hinting that they'd have
> > said so much earlier if someone had asked them).
>
> No, that's not right. There's an important distinction between
> "finding malicious JS code" and "finding _all_ malicious JS code". The
> latter is impossible, but the former isn't.
>

Note that malicious code here might look like this:

  console.log("success");

It's impossible to tell by looking at the code whether that line prints a
success message on the console, or something entirely different, such as
running calc.exe.

A better framing for the problem is "finding some arbitrary instances of
malicious JS code" vs "finding malicious JS code".  My point in the bug and
in the discussions prior to that was that a static checker can only do the
former, and as such, if the goal of the validator is finding malicious
code, its effectiveness is bound to be a lint tool at best.


> Proving "the validator won't catch everything" isn't particularly
> relevant when it isn't intended to, in the overall add-on signing
> system design.
>

The specific problem here is that we allow automatic signing of extensions
once they pass the add-on validator checks, and we allow our users to run
signed extensions without any other checks.  Therefore, the current system
is vulnerable to attacks such as what Dan's PoC extension has demonstrated.

No matter what the overall system design is and what the intended purpose
of the validator is, the concrete issue here is the vulnerability above.  I
admit that I don't have a great understanding of the goals and design of
the add-on signing process (even though I have tried hard to understand it
by looking at the public info we've published), but we cannot dismiss this
vulnerability because the validator is intended to do something different.

Cheers,
-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gavin Sharp]

The assumption that the validator must catch all malicious code for add-on 
signing to be beneficial is incorrect, and seems to be what's fueling most of 
this thread. Validation being a prerequisite for automatic signing is not 
primarily a security measure, but rather just a way of eliminating "obvious" 
problems (security-related or otherwise) from installed and enabled add-ons 
generally. With add-on singing fully implemented, if (when) malicious add-ons 
get automatically signed, you'll have several more effective tools to deal with 
them, compared to the status quo.

Gavin

> On Nov 27, 2015, at 8:49 PM, Eric Rescorla  wrote:
> 
> 
> 
>> On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari  
>> wrote:
>> On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp  wrote:
>> 
>> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham  wrote:
>> > > But the thing is, members of our security group are now piling into the
>> > > bug pointing out that trying to find malicious JS code by static code
>> > > review is literally _impossible_ (and perhaps hinting that they'd have
>> > > said so much earlier if someone had asked them).
>> >
>> > No, that's not right. There's an important distinction between
>> > "finding malicious JS code" and "finding _all_ malicious JS code". The
>> > latter is impossible, but the former isn't.
>> >
>> 
>> Note that malicious code here might look like this:
>> 
>>   console.log("success");
>> 
>> It's impossible to tell by looking at the code whether that line prints a
>> success message on the console, or something entirely different, such as
>> running calc.exe.
>> 
>> A better framing for the problem is "finding some arbitrary instances of
>> malicious JS code" vs "finding malicious JS code".  My point in the bug and
>> in the discussions prior to that was that a static checker can only do the
>> former, and as such, if the goal of the validator is finding malicious
>> code, its effectiveness is bound to be a lint tool at best.
> 
> Indeed.  And if the validator is publicly accessible, let alone has public
> source code, it's likely to be straightforward for authors of malicious
> code to evade the validator. All they need to do is run their code
> through the validator, see what errors it spits out, and modify the
> code until it no longer spits out errors.
> 
> Again, this goes back to threat model. If we're trying to make it easier
> for authors to comply with our policies (and avoid writing problematic
> add-ons), then a validator seems reasonable. However, if we're trying
> to prevent authors of malicious add-ons from getting their add-ons
> through, that seems much more questionable, for the reasons listed above.
> However, once we accept that we can't stop authors who are trying
> to evade detection, then treating it as a linter and allowing authors
> to override it seems a lot more sensible.
> 
> -Ekr
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Thomas Zimmermann]

Am 26.11.2015 um 18:14 schrieb WaltS48:

> Perhaps you missed.
>
> Add-ons/Extension Signing - MozillaWiki -
> 
>
> I've noticed a couple new items there about how an extension developer
> can get their extension signed if it isn't hosted on AMO.
>
>

Thanks for pointing to further information.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Thomas Zimmermann]

Am 25.11.2015 um 20:16 schrieb Jeff Gilbert:
> On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit
>  wrote:
>> FWIW, I received questions about this via private email and phone calls
>> from two people working on extensions that support their products. Their
>> extensions sit in the review queue with not chance of getting through it
>> before the signing requirement kicks in. This puts them into a situation
>> where their only reasonable course of action is to advise their users to
>> switch browsers.
>>
> Is it just me, or does this sounds completely unacceptable. Sloughing
> more users? Things like this are why it's hard not to be cynical.

It's not just you. Reading the blog post made me think that extension
signing is complete nonsense and we should stop it now. This will only
break one of Firefox' best features for nothing. And especially bad was
it to blacklist the proof-of-concept exploit, instead of addressing the
actual problem.

Best regards
Thomas

>
> I doubt anyone is going to switch to Firefox because our extension
> signing is safe. (though I do think we should have some form of
> signing) But they will gladly switch away when anything breaks,
> particularly when we reduce the activation energy needed to switch: If
> their extension won't work in new Firefox, it doesn't matter so much
> that they won't have that extension in, say, Chrome.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Till Schneidereit]

On Thu, Nov 26, 2015 at 10:02 AM, Thomas Zimmermann  wrote:

> Am 25.11.2015 um 20:16 schrieb Jeff Gilbert:
> > On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit
> >  wrote:
> >> FWIW, I received questions about this via private email and phone calls
> >> from two people working on extensions that support their products. Their
> >> extensions sit in the review queue with not chance of getting through it
> >> before the signing requirement kicks in. This puts them into a situation
> >> where their only reasonable course of action is to advise their users to
> >> switch browsers.
> >>
> > Is it just me, or does this sounds completely unacceptable. Sloughing
> > more users? Things like this are why it's hard not to be cynical.
>
> It's not just you. Reading the blog post made me think that extension
> signing is complete nonsense and we should stop it now. This will only
> break one of Firefox' best features for nothing. And especially bad was
> it to blacklist the proof-of-concept exploit, instead of addressing the
> actual problem.
>

I read the blog post, too, and if that were the final, uncontested word on
the matter, I think I would agree. As it is, this assessment strikes me as
awfully harsh: many people have put a lot of thought and effort into this,
so calling for it to simply be canned should require a substantial amount
of background knowledge.

I should also give a bit more information about the feedback I received: in
both cases, versions of the extensions exist for at least Chrome and
Safari. In at least one case, the extension uses a large framework that
needs to be reviewed in full for the extension to be approved. Apparently
this'd only need to happen once per framework, but it hasn't, yet. That
means that the review is bound to take much longer than if just the
extension's code was affected. While I think this makes sense, two things
strike me as very likely that make it a substantial problem: many authors
of extensions affected in similar ways will come out of the woodwork very
shortly before 43 is released or even after that, in reaction to users'
complaints. And many of these extensions will use large frameworks not
encountered before, or simply be too complex to review within a day or two.

I *do* think that we shouldn't ship enforced signing without having a solid
way of dealing with this problem. Or without having deliberately decided
that we're willing to live with these extensions' authors recommending (or
forcing, as the case may be) their users to switch browsers.


till
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Thomas Zimmermann]

Hi

Am 26.11.2015 um 13:56 schrieb Till Schneidereit:

> I read the blog post, too, and if that were the final, uncontested word on
> the matter, I think I would agree. As it is, this assessment strikes me as
> awfully harsh: many people have put a lot of thought and effort into this,
> so calling for it to simply be canned should require a substantial amount
> of background knowledge.

Ok, I take back the 'complete nonsense' part. There can be ways of
improving security that involve signing, but the proposed one isn't. I
think the blog post makes this obvious.


>
> I should also give a bit more information about the feedback I received: in
> both cases, versions of the extensions exist for at least Chrome and
> Safari. In at least one case, the extension uses a large framework that
> needs to be reviewed in full for the extension to be approved. Apparently
> this'd only need to happen once per framework, but it hasn't, yet. That
> means that the review is bound to take much longer than if just the
> extension's code was affected. While I think this makes sense, two things
> strike me as very likely that make it a substantial problem: many authors
> of extensions affected in similar ways will come out of the woodwork very
> shortly before 43 is released or even after that, in reaction to users'
> complaints. And many of these extensions will use large frameworks not
> encountered before, or simply be too complex to review within a day or two.

Thanks for this perspective. He didn't seem to use any frameworks, but
the review process failed for an apparently trivial case. Regarding
frameworks in general: there are many and there are usually different
versions in use. Sometimes people make additional modifications. So this
helps only partially.

And of course reviews are not a panacea at all. Our own Bugzilla is
proof of that. ;) Pretending that a reviewed extension (or any other
piece of code) is more trust-worthy is not credible IMHO. Code becomes
trust-worthy by working successfully in "the real world."

>
> I *do* think that we shouldn't ship enforced signing without having a solid
> way of dealing with this problem. Or without having deliberately decided
> that we're willing to live with these extensions' authors recommending (or
> forcing, as the case may be) their users to switch browsers.

I think, a good approach would be to hand-out signing keys to extension
developers and require them to sign anything they upload to AMO. That
would establish a trusted path from developers to users; so users would
know they downloaded the official release of an extension. A malicious
extensions can then be disabled/blacklisted by simply revoking the keys
and affected users would notice. For anything non-AMO, the user is on
their own.

Best regards
Thomas

>
>
> till
>

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Kartikaya Gupta]

On Thu, Nov 26, 2015 at 8:50 AM, Thomas Zimmermann
 wrote:
> For anything non-AMO, the user is on
> their own.
>

I don't know if that would fly. As I understand it, a large part of
the purpose of extension signing is to protect users from malicious
add-ons that get installed by non-AMO means - sideloading, installed
by other apps, and so on. If we ignore the non-AMO add-ons then we're
not really solving any problems worth solving. (Caveat: I don't have
access to any actual data on the numbers and types of malicious
add-ons, but from what I've heard I believe this to be the case. I
could be wrong.)

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[David Burns]

Another data point that we seem to have overlooked is that users want to be
able to side load their extensions for many different reasons. We see this
with apps on phones and with extensions currently. I appreciate that users
have grown to be warning blind but, as others have pointed out, this feels
like a sure way to have users move from us to Chrome if there extension
lives there too. Once they are lost it will be non-trivial to get them back.

My main gripe is that we will be breaking tools like WebDriver[1] (better
known as Selenium) and not once have we approached that community. Luckily
we have Marionette being developed as a replacement for them, and was being
developed before we started the addon signing. When mentioned I was told
that since it instruments the browser it can never get signed and we need
to get a move on or get everyone to change to the "whitelabel" version to
use WebDriver. Having spoke to peers at other large tech companies they
said no, they will remain on older versions and if it breaks then stop
support for it until they have a like for like replacement. They will stop
caring about WebCompat until they have a like for like replacement. We will
drive away other users because Firefox does work as well on their favourite
website.

There are also companies that have developed internal tools in addons that
they don't want in AMO. We are essentially telling them that we don't care
about how much effort they have put in or how "sooper sekrit" their addon
is. It's in AMO or else...

I honestly thought we would do the "signing keys to developers" approach
and revoke when they are being naughty.

David

[1] http://github.com/seleniumhq/selenium

On 26 November 2015 at 13:50, Thomas Zimmermann 
wrote:

> Hi
>
> Am 26.11.2015 um 13:56 schrieb Till Schneidereit:
>
> > I read the blog post, too, and if that were the final, uncontested word
> on
> > the matter, I think I would agree. As it is, this assessment strikes me
> as
> > awfully harsh: many people have put a lot of thought and effort into
> this,
> > so calling for it to simply be canned should require a substantial amount
> > of background knowledge.
>
> Ok, I take back the 'complete nonsense' part. There can be ways of
> improving security that involve signing, but the proposed one isn't. I
> think the blog post makes this obvious.
>
>
> >
> > I should also give a bit more information about the feedback I received:
> in
> > both cases, versions of the extensions exist for at least Chrome and
> > Safari. In at least one case, the extension uses a large framework that
> > needs to be reviewed in full for the extension to be approved. Apparently
> > this'd only need to happen once per framework, but it hasn't, yet. That
> > means that the review is bound to take much longer than if just the
> > extension's code was affected. While I think this makes sense, two things
> > strike me as very likely that make it a substantial problem: many authors
> > of extensions affected in similar ways will come out of the woodwork very
> > shortly before 43 is released or even after that, in reaction to users'
> > complaints. And many of these extensions will use large frameworks not
> > encountered before, or simply be too complex to review within a day or
> two.
>
> Thanks for this perspective. He didn't seem to use any frameworks, but
> the review process failed for an apparently trivial case. Regarding
> frameworks in general: there are many and there are usually different
> versions in use. Sometimes people make additional modifications. So this
> helps only partially.
>
> And of course reviews are not a panacea at all. Our own Bugzilla is
> proof of that. ;) Pretending that a reviewed extension (or any other
> piece of code) is more trust-worthy is not credible IMHO. Code becomes
> trust-worthy by working successfully in "the real world."
>
> >
> > I *do* think that we shouldn't ship enforced signing without having a
> solid
> > way of dealing with this problem. Or without having deliberately decided
> > that we're willing to live with these extensions' authors recommending
> (or
> > forcing, as the case may be) their users to switch browsers.
>
> I think, a good approach would be to hand-out signing keys to extension
> developers and require them to sign anything they upload to AMO. That
> would establish a trusted path from developers to users; so users would
> know they downloaded the official release of an extension. A malicious
> extensions can then be disabled/blacklisted by simply revoking the keys
> and affected users would notice. For anything non-AMO, the user is on
> their own.
>
> Best regards
> Thomas
>
> >
> >
> > till
> >
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org

Re: Dan Stillman's concerns about Extension Signing

[Thomas Zimmermann]

Hi,

I haven't followed the overall discussion closely, but I'm very
concerned about this change and that we're driving away extension
developers. I hope that some of the relevant people read this thread, as
I'd like to propose a different strategy for extension signing.

1) As dburns mentioned in this thread, some people have to run unsigned
extensions. We should continue to allow this if the users explicitly
enables it in about:config. Unsigned extensions are disabled by default
and should come with a big warning sign.

2) If extension signing is enabled (the default), Firefox should only
allow for extensions that have been signed by a Mozilla-generated key.

3) Obtaining a signing key from Mozilla should be automated in a way
similar to Let's Encrypt. So the overhead for extension developers is
minimal.

4) Keys should be bound to URLs and there can only be one URL per
extension. So it's not possible to modify and redistribute someone
else's extension.

5) Changing an extension's URL requires manual intervention.

6) If an extension turns out to be malicious we can revoke the key.
Firefox would then notice all affected users and disable the extension
automatically.

7) Popular extensions on AMO should be reviewed by Mozilla staff 'behind
the scenes' and get an additional quality label or something similar.

Best regards
Thomas


Am 25.11.2015 um 10:14 schrieb David Rajchenbach-Teller:
> I admit I have followed extension signing/scanning only very remotely,
> but Dan Stillman has a number of good points:
>
> http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
>
> Could someone who's actually involved in this feature provide an answer?
>
> Cheers,
>  David
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Gijs Kruitbosch]

On 26/11/2015 16:07, Thomas Zimmermann wrote:

Hi,

I haven't followed the overall discussion closely, but I'm very
concerned about this change and that we're driving away extension
developers. I hope that some of the relevant people read this thread, as
I'd like to propose a different strategy for extension signing.

1) As dburns mentioned in this thread, some people have to run unsigned
extensions. We should continue to allow this if the users explicitly
enables it in about:config. Unsigned extensions are disabled by default
and should come with a big warning sign.


This really misses the point. There have been many discussions about 
this in the past. If we just use an about:config flag, malware/greyware 
will set that in the user's pref file and then install itself anyway 
(unsigned, obviously). There is nothing we can do in the UI if an 
untrusted extension is installed permanently that that untrusted 
extension won't be able to hide anyway.


For the signing to provide any meaningful protection, it needs to be 
impossible to turn it off permanently.


If users want to run unsigned extensions repeatedly (rather than 
one-offs for testing, for which support was recently added), they can 
either self-build, or run unbranded builds, or run nightly or aurora. 
IIRC 43 will still ship with a pref to turn off signing, and 44 won't 
anymore.


Please read earlier discussions about this to get more context before 
proposing alternatives.


~ Gijs

(who, ftr, is not on the add-on team or "relevant people" - just happens 
to have been following this discussion for a long time)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Mike Hoye]

On 2015-11-26 11:07 AM, Thomas Zimmermann wrote:


I haven't followed the overall discussion closely, but

This is not OK.

Does anyone here actually think that the team that's been busting their 
asses over this for months _doesn't_ have better information and more 
insight into this problem than what you've come up with after thinking 
about it for five minutes? That all the data they've gathered, all the 
experience and expertise they're bringing to bear on this problem are 
just sitting in a box in the corner somewhere while they daydream how 
much fun it is to write security-critical software and brush off our 
users' rights and developer community's needs?


Really?

Stillman wrote some new code and put it through a process meant to catch 
problems in old code, and it passed. That's unfortunate, but does it 
really surprise anyone that security is an evolving process? That it 
might be be full of hard tradeoffs? There is a _huge_gap_ between "new 
code can defeat old security measures" and "therefore all the old 
security measures are useless". It's an even bigger step from there to 
the implication that people working on this either haven't thought about 
it already, or just don't care.


We're bad at communications, I get that, but maybe we could all talk to 
someone on that team for ten minutes before telling them how to do their 
jobs. Ask them about their reasoning, what decisions they made and why, 
what the tradeoffs were. I have, and watching the discussion in this 
thread is like watching someone tell Jason Bourne he should tie his 
shoes and look both ways before crossing the street. It would be 
hilarious if I didn't know for a fact that it's insulting and 
demoralizing to really smart people who've worked hard and cared 
intensely about Mozilla's users and developers for a long, long time.




- mhoye



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[WaltS48]

On 11/26/2015 11:07 AM, Thomas Zimmermann wrote:

Hi,

I haven't followed the overall discussion closely, but I'm very
concerned about this change and that we're driving away extension
developers. I hope that some of the relevant people read this thread, as
I'd like to propose a different strategy for extension signing.

1) As dburns mentioned in this thread, some people have to run unsigned
extensions. We should continue to allow this if the users explicitly
enables it in about:config. Unsigned extensions are disabled by default
and should come with a big warning sign.

2) If extension signing is enabled (the default), Firefox should only
allow for extensions that have been signed by a Mozilla-generated key.

3) Obtaining a signing key from Mozilla should be automated in a way
similar to Let's Encrypt. So the overhead for extension developers is
minimal.

4) Keys should be bound to URLs and there can only be one URL per
extension. So it's not possible to modify and redistribute someone
else's extension.

5) Changing an extension's URL requires manual intervention.

6) If an extension turns out to be malicious we can revoke the key.
Firefox would then notice all affected users and disable the extension
automatically.

7) Popular extensions on AMO should be reviewed by Mozilla staff 'behind
the scenes' and get an additional quality label or something similar.

Best regards
Thomas




Perhaps you missed.

Add-ons/Extension Signing - MozillaWiki - 



I've noticed a couple new items there about how an extension developer 
can get their extension signed if it isn't hosted on AMO.



--
Linux Mint 17.2 "Rafaela" | KDE 4.14.2 | Thunderbird 45.0a1 (Daily)
You don't need zero-days when machines wherever are packed with old-days.
Go Bucs! (next season) Go Pens! Go Sabres! Go Pitt!
[Visit Pittsburgh]
[Coexist · Understanding Across Divides]

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[David Rajchenbach-Teller]

For what it's worth, this thread was not meant to point fingers, but
specifically to get an answer from said team. I see concern about
Extension Signing, and I see points made by add-on developers and which
appear valid to me and which I am unable to answer.

That doesn't mean that we have done something wrong, but it is
sufficient to get my spider(monkey)-sense tingling. We have had cases in
the past where teams have « been busting their asses over [some feature]
for months » and we realized too late that the feature was not aligned
with what we needed. I have no idea whether this is the case here, hence
the need to communicate.

As a side-note, yeah, it would be great if signing add-ons was as simple
as using Let's Encrypt, without having to pile even more work upon an
understaffed team of reviewers.

Best regards,
 David

On 26/11/15 18:13, Mike Hoye wrote:
> On 2015-11-26 11:07 AM, Thomas Zimmermann wrote:
>>
>> I haven't followed the overall discussion closely, but
> This is not OK.
> 
> Does anyone here actually think that the team that's been busting their
> asses over this for months _doesn't_ have better information and more
> insight into this problem than what you've come up with after thinking
> about it for five minutes?

[...]

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Philip Chee]

On 27/11/2015 00:07, Thomas Zimmermann wrote:

> I haven't followed the overall discussion closely, but I'm very
> concerned about this change and that we're driving away extension
> developers. I hope that some of the relevant people read this thread, as
> I'd like to propose a different strategy for extension signing.


NOT THAT I DISAGREE WITH YOU (I am an extension developer too) but in
the original discussion months ago. All your points were raised and
ultimately dismissed [1]. Rehashing this won't change anybodies mind.

[1] jorgev and John-Galt can give you the gory details.

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Jorge Villalobos]

On 11/26/15 11:51 AM, David Rajchenbach-Teller wrote:
> For what it's worth, this thread was not meant to point fingers, but
> specifically to get an answer from said team. I see concern about
> Extension Signing, and I see points made by add-on developers and which
> appear valid to me and which I am unable to answer.
> 
> That doesn't mean that we have done something wrong, but it is
> sufficient to get my spider(monkey)-sense tingling. We have had cases in
> the past where teams have « been busting their asses over [some feature]
> for months » and we realized too late that the feature was not aligned
> with what we needed. I have no idea whether this is the case here, hence
> the need to communicate.
> 
> As a side-note, yeah, it would be great if signing add-ons was as simple
> as using Let's Encrypt, without having to pile even more work upon an
> understaffed team of reviewers.
> 
> Best regards,
>  David
> 
> On 26/11/15 18:13, Mike Hoye wrote:
>> On 2015-11-26 11:07 AM, Thomas Zimmermann wrote:
>>>
>>> I haven't followed the overall discussion closely, but
>> This is not OK.
>>
>> Does anyone here actually think that the team that's been busting their
>> asses over this for months _doesn't_ have better information and more
>> insight into this problem than what you've come up with after thinking
>> about it for five minutes?
> 
> [...]
> 

Unfortunately, this discussion has been going on in too many places,
which is why I would like to keep it focused in the
mozilla.addons.user-experience group, which is where most of it is
happening.

This project has been discussed to death for years now, but it's only
getting into some people's radar until now, so it's understandable that
there are lots of old questions coming up, and some of us are responding
a bit impatiently.

We knew going into this that it would alienate a subset of the add-on
developer community, just like we know that dropping features in Firefox
will lose us some users, but help us in the long term. That doesn't mean
we're just dismissing all criticism, and we're discussing making some
adjustments to improve things for developers. Given that many people are
away for Thanksgiving Day, I don't expect anything to happen until early
next week. I'll make sure something is posted on this thread.

Jorge
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Chris Peterson]

On 11/25/15 11:16 AM, Jeff Gilbert wrote:

I doubt anyone is going to switch to Firefox because our extension
signing is safe. (though I do think we should have some form of
signing) But they will gladly switch away when anything breaks,
particularly when we reduce the activation energy needed to switch: If
their extension won't work in new Firefox, it doesn't matter so much
that they won't have that extension in, say, Chrome.


And that assumes the same extension, or an equivalent, is not available 
for Chrome. Picking a not-so-random example, Zotero has a Chrome extension:


https://chrome.google.com/webstore/detail/zotero-connector/ekhagklcjbdpajgpjgmbionohlpdbjgc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Jeff Gilbert]

On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit
 wrote:
> FWIW, I received questions about this via private email and phone calls
> from two people working on extensions that support their products. Their
> extensions sit in the review queue with not chance of getting through it
> before the signing requirement kicks in. This puts them into a situation
> where their only reasonable course of action is to advise their users to
> switch browsers.
>

Is it just me, or does this sounds completely unacceptable. Sloughing
more users? Things like this are why it's hard not to be cynical.

I doubt anyone is going to switch to Firefox because our extension
signing is safe. (though I do think we should have some form of
signing) But they will gladly switch away when anything breaks,
particularly when we reduce the activation energy needed to switch: If
their extension won't work in new Firefox, it doesn't matter so much
that they won't have that extension in, say, Chrome.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Mike Hommey]

On Wed, Nov 25, 2015 at 10:14:09AM +0100, David Rajchenbach-Teller wrote:
> I admit I have followed extension signing/scanning only very remotely,
> but Dan Stillman has a number of good points:
> 
> http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
> 
> Could someone who's actually involved in this feature provide an answer?

As mentioned in the blog post, he posted an abridged version to
firefox-dev.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[David Rajchenbach-Teller]

And didn't receive any reply, afaict.

On 25/11/15 10:30, Mike Hommey wrote:
> On Wed, Nov 25, 2015 at 10:14:09AM +0100, David Rajchenbach-Teller wrote:
>> I admit I have followed extension signing/scanning only very remotely,
>> but Dan Stillman has a number of good points:
>>
>> http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
>>
>> Could someone who's actually involved in this feature provide an answer?
> 
> As mentioned in the blog post, he posted an abridged version to
> firefox-dev.
> 
> Mike
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Till Schneidereit]

FWIW, I received questions about this via private email and phone calls
from two people working on extensions that support their products. Their
extensions sit in the review queue with not chance of getting through it
before the signing requirement kicks in. This puts them into a situation
where their only reasonable course of action is to advise their users to
switch browsers.

On Wed, Nov 25, 2015 at 10:31 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:

> And didn't receive any reply, afaict.
>
> On 25/11/15 10:30, Mike Hommey wrote:
> > On Wed, Nov 25, 2015 at 10:14:09AM +0100, David Rajchenbach-Teller wrote:
> >> I admit I have followed extension signing/scanning only very remotely,
> >> but Dan Stillman has a number of good points:
> >>
> >>
> http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
> >>
> >> Could someone who's actually involved in this feature provide an answer?
> >
> > As mentioned in the blog post, he posted an abridged version to
> > firefox-dev.
> >
> > Mike
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform