On 5/2/16 2:15 PM, Aryeh Gregor wrote:
If the idea is to stop stack overflow, it doesn't make sense to me to
have the check in the parser at all. It should be on the DOM level.
Otherwise, scripts could make an arbitrarily deep stack, like this:
Now we enter the discussion of threat models.
Scripts of the sort you describe are incredibly rare, not least because
they're hard to write by accident. So while you're right that such
scripts can be created, and can trigger stack overflow in layout/DOM
algorithms, in practice this has not been much of an issue.
On the other hand, broken HTML generators that forget to close all or
some of their tags (e.g. by spitting out things like "<span/>" in HTML,
or dumping mailbox files, complete with "<f...@bar.com>" all over, out as
"HTML") are common as dirt. The parser mitigation is perfectly
sufficient for the latter and was put in to deal with them.
Which outputs 10000. And indeed, removing the last line of the script
causes an immediate tab crash both in Firefox and Chrome. So if this
is a security issue, we're vulnerable right now.
It's a DOS issue, not a security issue. And accidental DOS in the
common cases at that; see above. At least assuming we crash. If we
attempt to not crash _that's_ when you can get security issues due to
data structures being left in an inconsistent state. So from a security
point of view, crashing on stack overflow is vastly preferable to trying
to recover from it.
Oh, and once you're talking about script, the DOS possibilities are of
course quite varied. I mean, you can simply OOM the process pretty easily!
If Firefox and Chrome
both have parser depth limits but not script-exposed depth limits,
probably that's because a non-negligible number of sites historically
hit the parser depth limits, but scripts haven't been much of an
issue.
Yes, see above.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
