[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042



Antoine Beaupré <anarcat@orangeseeds.org> writes:

> On 2018-08-08 17:35:52, Brian May wrote:
>> If I got this right, we cannot use $(xyz) unless the value of xyz is
>> trusted. Otherwise executing $(xyz) can result in the execution of code
>> if xyz is something like "<img src=1 onerror=alert(123) />". This
>> happens immediately, and even if you don't use the return value.
>
> I am a bit puzzled as to how this attack works, but I'm ready to accept
> that as yet another jQuery excentricity. :)

So my understanding only, $(...) has been overloaded and has a number of
distinct uses.

You can use it to look up a value, e.g.:

$("#myid")

You can use it to create a DOM element:

$("<div>ABC</div>")

Or:

$("<img src=1 onerror=alert(123) />")

This will not only create the dom element, and try to preload the
image. When this fails, the onerror hook is called.

You could also use it to wrap a JS DOM element in a jquery selector, but
this use isn't so relevant here.

The problem occurs as this code does lookups on untrusted values like:

$(untrusted_input)

The problem being if untrusted_input can change the mode from "lookup"
to "create" which in turn assumes that the data passed is trusted.

I think the real problem here is poor jquery API, however I doubt this
is going to change anytime soon as this would break everything that uses
jquery.
-- 
Brian May <bam@debian.org>


Reply to: