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 <e...@rtfm.com
<mailto:e...@rtfm.com>> wrote:
On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari
<ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote:
On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp
<ga...@gavinsharp.com <mailto:ga...@gavinsharp.com>> wrote:
> On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham <g...@mozilla.org
<mailto:g...@mozilla.org>> 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
