1559731 - Input with expensive pattern provides a convenient DoS attack, even on an inert DOM

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Chris Morgan]

This is a weaponised form of bug 1437914. I decided to file a new bug about it due to this severity and potential for attack, and the fact that this aspect of it is Firefox-specific and not a general weakness of the web platform. Nonetheless, it could be fair to merge it back into that bug.

The gist of it is this HTML, with a pathological regular expression and input to trigger that pathological case:

<input pattern=^((a+.)a)+$ value=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!>'

(Don’t try running that at home.)

In both Firefox and Chrome, writing such an element in your document causes Firefox and Chrome content processes to hang roughly indefinitely.

But the real problem is either of these two snippets, which are how HTML defangers/sanitisers/purifiers will try to work:

new DOMParser().parseFromString('<input pattern=^((a+.)a)+$ value=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!>', 'text/html')

document.createElement('div').innerHTML = '<input pattern=^((a+.)a)+$ value=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!>';

In Chrome, neither of these trigger validation of the value: it seems to only trigger validation once you insert it into the document and focus the window. But in Firefox, the validation is performed immediately, and so the parseFromString function call and the innerHTML assignment ~never return.

The end result of all of this is a practical DoS attack that we can’t reasonably intercept in the FastMail webmail in Firefox, because the damage has already been done before the stage where we’d blacklist the pattern attribute in our inert-DOM-based defanging.

I’d say that the solution to bug 1437914 would be an evaluation time limit on the pattern; and that would incidentally solve (or at least mitigate) this specific case. But here, I believe the proper solution is lazy validation, implying that validation will generally only be done when the input is inserted into the document.

Comment 1

[Makoto Kato [:m_kato]]

I guess that pattern matching isn't editor.
HTMLInputElement::UpdatePatternMismatchValidityState and https://searchfox.org/mozilla-central/rev/7e158713cf5a8514fa8161dd4a239737b05da64d/dom/base/nsContentUtils.cpp#6374.

If this should consider editor component, please back to editor.