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
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
