Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On 2018-09-02 17:08:09, Brian May wrote: > Antoine Beaupré writes: > >> What do you think? Should we push this forward? > > I am somewhat concerned that by fixing this we might be breaking > something. Even if it is 100% broken behaviour, maybe some application > depends on this? > > Is the potential attack bad enough to justify potential breakage? I am > not absolutely convinced. Well there *are* probably some XSS left. The solution would be similar to the one I did in the DLA with little or no breakage. A. -- The class which has the power to rob upon a large scale has also the power to control the government and legalize their robbery. - Eugene V. Debs
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
Antoine Beaupré writes: > What do you think? Should we push this forward? I am somewhat concerned that by fixing this we might be breaking something. Even if it is 100% broken behaviour, maybe some application depends on this? Is the potential attack bad enough to justify potential breakage? I am not absolutely convinced. -- Brian May
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On 2018-08-29 12:23:54, Brian May wrote:
> Antoine Beaupré 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 "". 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:
>
> $("ABC")
>
> Or:
>
> $("")
>
> 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
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
Antoine Beaupré 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 "". 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:
$("ABC")
Or:
$("")
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
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
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 "". This
> happens immediately, and even if you don't use the return value.
>
>
> I believe this fixes CVE-2018-14040 in Jessie:
>
> --- twitter-bootstrap-2.0.2+dfsg.orig/js/bootstrap-collapse.js
> +++ twitter-bootstrap-2.0.2+dfsg/js/bootstrap-collapse.js
> @@ -26,7 +26,7 @@
> this.options = $.extend({}, $.fn.collapse.defaults, options)
>
> if (this.options["parent"]) {
> - this.$parent = $(this.options["parent"])
> + this.$parent = $(document.querySelector(this.options["parent"]))
> }
>
> this.options.toggle && this.toggle()
>
>
> I think an alternative option here would be to replace $(xyz) with
> $(document).find(xyz) - as used in the upstream patch for
> CVE-2018-14042.
I am a bit puzzled as to how this attack works, but I'm ready to accept
that as yet another jQuery excentricity. :)
> CVE-2018-14041 / CVE-2018-14042 both refer to code that I cannot find in
> Jessie, hence I do not think they apply.
However, when trying to reproduce this online, I am failing to do so
with the version numbers matching those in Debian. Here are "pastebins"
which actually run the XSS with various versions, as provided in one of
the upstream bug reports (CVE-2018-14042):
https://github.com/twbs/bootstrap/issues/26628
The original, with 4.1.1:
https://jsbin.com/bimipayoda/edit?html,output
The same, with 3.3.7 (stretch, sid):
https://jsbin.com/nakisuhuso/edit?html,output
3.2.0 (jessie):
https://jsbin.com/tafejagene/edit?html,output
2.0.2 (jessie, stretch, sid):
https://jsbin.com/zapefecije/edit?html,output
Only the 4.1.1 codebase triggers the mouse-over XSS when running in
Firefox 60 or Chromium 68. So I can confirm that both CVE-2018-14041 and
CVE-2018-14042 a n/a in jessie and have marked them as such in the
tracker.
In my tests, only CVE-2018-14040 actually triggers a XSS, and only with
3.2.0. So I've marked 2.x N/A there as well..
> Looking at the code I do see a number of other references to $(xyz)
> where xyz is potentially untrusted, so simply applying the above patch
> may not be sufficient to fixing the problem. e.g. in
> js/bootstrap-scrollspy.js I see:
>
> var href = $(this).attr('href')
>
> return /^#\w/.test(href) && $(href).length ? href : null
>
>
> While this one might be obvious, there any many others that are not so
> clear. So I am not sure if I should fix only the instances fixed by
> these CVEs or search for everything I can find.
I would focus on those issues for now. CVEs have been pretty
systematically assigned and auditing the entire bootstrap codebase does
not seem realistic to me. And if we do, it would mean going into another
round of CVE assigment and upstream communication.
It might be worth, however, pinpointing that fact upstream, which I have
done here:
https://github.com/twbs/bootstrap/issues/26628#issuecomment-416282154
I've also posted in the other issues to validate the above claims.
In the meantime, I'll see if I can issue a patch for CVE-2018-14040
directly.
Sounds good?
A.
--
Pour marcher au pas d'une musique militaire, il n'y a pas besoin de
cerveau, une moelle épinière suffit.
- Albert Einstein
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On Thu, 2018-08-09 at 16:57 +1000, Brian May wrote: > I could still ping the host, so probably not a routing problem. Next time try connecting to port 80/443 on the IP address without sending any data. That would eliminate a HTTP-layer issue. > Looks like I can connect today however, so maybe transient blackhole? Or temporary overload. If it happens again, the curl output of the IP address will tell you which StackPath datacenter you connected to and it does not go to the security-tracker hostname so it should return results immediately and might be blacklist independent. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
Paul Wise writes: > The site has been moved to MaxCDN so it is likely that they have > blackholed your network or there is some sort of routing issue between > you and their local node. I could still ping the host, so probably not a routing problem. Looks like I can connect today however, so maybe transient blackhole? -- Brian May
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On Wed, Aug 8, 2018 at 3:35 PM, Brian May wrote: > Sidenote: Curiously I cannot connect to > https://security-tracker.debian.org/ today from this machine on this > network... Connections always time out. Probably something weird with my > network, however other webpages appear to be fine. If I ssh into my home > computer and use w3m it works fine. The site has been moved to MaxCDN so it is likely that they have blackholed your network or there is some sort of routing issue between you and their local node. -- bye, pabs https://wiki.debian.org/PaulWise
