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