Friday's security updates [LWN.net]

Hmph.

Posted Mar 30, 2012 19:18 UTC (Fri) by corbet (editor, #1) [Link]

OK, we're amused, hope you had fun.

Here's the deal...it seems there is a difference of opinion between Firefox and the Python HTMLparser module on what "<!-->" means. Firefox interprets as the beginning and the end of an HTML comment, while HTMLparser thinks it's only the beginning. That allowed our well-named prankster to slip a bit of otherwise prohibited markup past the checker.

I've done a bit of digging, and I think HTMLparser is right by the standard. The "<--" sequence starts a comment; a second "--" is needed to end it. But Firefox, at least, disagrees, with the results seen here.

We have just put in a quick patch to disable HTML comments altogether, so this particular problem should not afflict us again. Thanks to "slashdot" for bringing the problem to our attention, though it must be said we would prefer a nice email.

Hmph.

Posted Mar 30, 2012 19:35 UTC (Fri) by geofft (subscriber, #59789) [Link]

You should publish the code -- even if it's just a single code drop with no docs, and not actually under a free license -- so that other people can audit the code for vulnerabilities like they do for Tarsnap.

Of course, if you were to actually put a free license on it and put up a git repo, I wouldn't complain. :-)

Hmph.

Posted Mar 30, 2012 19:36 UTC (Fri) by Darkmere (subscriber, #53695) [Link]

Kudos to you for not removing the garish and utterly annoying proof of concept! (Not sarcastic this time.)
It turns out to be a rather interesting bug there I'd say, and a lovely comparision of how standards are interpreted.

Hmph.

Posted Mar 30, 2012 19:48 UTC (Fri) by slashdot (guest, #22014) [Link]

Wow, less than an hour from publication to mitigation!

Take that, distributions who want to embargo security holes for weeks or months, despite having orders of magnitude more employees and security bug experience than LWN!

Back to the topic at hand, the fundamental issue is that you seem to be copying the HTML verbatim after a check is passed, which, as you can see, is a rather dangerous practice, because it can fail catastrophically when the check doesn't quite work as expected.

A much better approach which should guarantee security is to parse the comment, and then generate completely new HTML based on the logical parse tree, making sure the code only outputs fixed safe HTML snippets (such as "<b>") or HTML-escaped strings; finally, check that the newly generated HTML is a well-formed XHTML fragment and automatically report the issue to the site administrator if isn't, with rate limiting.

Hmph.

Posted Mar 30, 2012 20:00 UTC (Fri) by slashdot (guest, #22014) [Link]

BTW, regarding the specific issue, <!--> starts a comment in XML/XHTML, but not in HTML (where it is a parse error that returns to the parser to the normal state, see HTML5 12.2.4.46 "Comment start state", 3rd case).

Browsers use the HTML parsing rules for this page, while Python HTMLparser either uses the XHTML ones, or is simply broken.

Hmph.

Posted Mar 31, 2012 15:53 UTC (Sat) by pdewacht (subscriber, #47633) [Link]

Isn't HTMLparser implementing the official HTML4/SGML comment rules, while browsers have mostly only implemented approximations of those rules?

Hmph.

Posted Mar 31, 2012 22:37 UTC (Sat) by foom (subscriber, #14868) [Link]

Browsers implemented the HTML5 parsing rules instead. (way, way before HTML5 even existed, of course)