Security/Reviews/Firefox4/HTML5 Parser Security Review: Difference between revisions

Line 21: Line 21:


* What potential security issues in your feature have you already considered and addressed?
* What potential security issues in your feature have you already considered and addressed?
I have considered the security issues that the spec itself addresses (see immediately above).


Gecko's layout system runs algorithms that are recursive along the depth of the DOM tree. This means that deep trees lead to an overflow of the runtime stack, especially on Windows. The HTML5 parser limits the depth of the tree it creates to 200. This works against DoS-by-incompetence but not against DoS-by-malice (since deep trees can be created by other means).
Gecko's layout system runs algorithms that are recursive along the depth of the DOM tree. This means that deep trees lead to an overflow of the runtime stack, especially on Windows. The HTML5 parser limits the depth of the tree it creates to 200. This works against DoS-by-incompetence but not against DoS-by-malice (since deep trees can be created by other means).
Line 33: Line 35:


When the tag <isindex> is parsed, a string that depends on the UI localization of the browser is inserted into the resulting DOM. An untrusted JavaScript program can use this string to obtain configuration-dependent entropy for fingerprinting or can infer the UI locale of the user. However, Gecko already leaks this data elsewhere.
When the tag <isindex> is parsed, a string that depends on the UI localization of the browser is inserted into the resulting DOM. An untrusted JavaScript program can use this string to obtain configuration-dependent entropy for fingerprinting or can infer the UI locale of the user. However, Gecko already leaks this data elsewhere.
[http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#reconstruct-the-active-formatting-elements Reconstructing active formatting elements] can make the DOM grow more than linearly as a function of the length of the input. This makes DoS attacks by resource exhaustion easy. [http://lists.w3.org/Archives/Public/public-html/2010Sep/0163.html Mitigations are being considered].
RAM can be exhausted by sending a lot of data to the HTML5 parser. For example, element and attribute names and attribute values get buffered until they've been completely seen, so a server-side script can serve an infinitely long attribute value to exhaust RAM on the client. This is not an attack point _introduced_ by the HTML5 parser, since the old parser had this attack point as well. However, the HTML5 parser's reliance on "infallible" malloc might make RAM exhaustion lead to a crash more often. As a mitigating factor on desktops, the rate at which the network can feed the parser is low enough relative to the available memory that the user can stop the load of pages that consume excessive RAM due to being large for non-malicious reasons. However, a malicious attacker could use gzip bombs to work around the rate at which the network can feed the parser.


* How are transitions in/out of Private Browsing mode handled?
* How are transitions in/out of Private Browsing mode handled?
254

edits