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

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



On 2018-08-29 12:23:54, Brian May wrote:
> 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.

Right, of course. That makes sense, somewhat.

> 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.

Indeed. As far as Bootstrap is concerned, they are just going away from
that API at this point and use native lookups without side-effects:

https://github.com/twbs/bootstrap/issues/26643

But unfortunately, that work was done only in Bootstrap 4, which is not
even in Debian yet.

There are, unfortunately, a non-trivial number of packages depending on
bootstrap (even v2!) in the archive still, otherwise I would propose to
just remove the damn things and get it over with.

I guess the proper process here would be to actually test a few
instances to see if we are still vulnerable and open issues (CVE?
upstream?) to track those.

What do you think? Should we push this forward?

A.
-- 
Freedom of speech is a principal pillar of a free government; when
this support is taken away, the constitution of a free society is
dissolved, and tyranny is erected on its ruins.
                        - Benjamin Franklin, 1737


Reply to: