254
edits
Security/Reviews/Firefox4/HTML5 Parser Security Review: Difference between revisions
Security/Reviews/Firefox4/HTML5 Parser Security Review (view source)
Revision as of 13:58, 27 September 2010
, 27 September 2010→Security and Privacy
| Line 38: | Line 38: | ||
[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]. | [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. | 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. A previous attempt to use an arbitrary limit failed; see {{bug|554513}}. | ||
* How are transitions in/out of Private Browsing mode handled? | * How are transitions in/out of Private Browsing mode handled? | ||