> 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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> >>> On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham <[email protected] >>> <mailto:[email protected]>> 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 [email protected] https://lists.mozilla.org/listinfo/dev-platform
