"Chris Lamb" <la...@debian.org> writes:
> I did consider this. However, as I implied last time — and you have
> independently discovered! — Javascript development is very weird with
> lots of edge-cases, and that is before we consider the inconsistencies
> of a higher-level API like jQuery and the underlying DOM APIs etc.
> etc.
should be fine... But we probably should make sure we don't export a new
API method for parseHTML, this could affect client code.
But... surprise surprise, it looks like buildFragment may be broken:
=== code ===
jQuery.buildFragment = function( args, nodes, scripts ) {
var fragment, cacheable, cacheresults, doc,
first = args[ 0 ];
// nodes may contain either an explicit document object,
// a jQuery collection or context object.
// If nodes[0] contains a valid object to assign to doc
if ( nodes && nodes[0] ) {
doc = nodes[0].ownerDocument || nodes[0];
}
// Ensure that an attr object doesn't incorrectly stand in as a
document object
// Chrome and Firefox seem to allow this to occur and will throw
exception
// Fixes #8950
if ( !doc.createDocumentFragment ) {
doc = document;
}
=== code ===
When I test this with the exploit, this fails, because the first if
statement fails, and hence doc is not assigned a value for the second if
statement.
In typical fashion, it looks like this function is completely different
in master:
https://github.com/jquery/jquery/blob/9c98e4e86eda857ee063bc48adbc1a11bb5506ee/src/manipulation/buildFragment.js
Will investigate further, in case there is a simple fix.
--
Brian May <b...@debian.org>
