Javascript libraries with vulnerabilities

[Stephan Pampel]

A security scan executed by a customer detected javascript libraries with known vulnerabilities in horizon dashboard on focal ussuri (3:18.3.4-0ubuntu1):

# libraries with vulnerabilities

## jQuery 1.12.4
* https://github.com/jquery/jquery/issues/2432

## jQuery Migrate 1.2.1
* http://bugs.jquery.com/ticket/11290

## AngularJS 1.5.8
* https://github.com/angular/angular.js/commit/726f49dcf6c23106ddaf5cfd5e2e592841db743a
* https://github.com/angular/angular.js/blob/master/CHANGELOG.md#179-pollution-eradication-2019-11-19
* https://nvd.nist.gov/vuln/detail/CVE-2020-7676

The libraries are included via https://github.com/openstack/horizon/blob/stable/ussuri/requirements.txt

Is it possible to updated these libraries and release an updated package?

[Jeremy Stanley (fungi)]

It looks like the Ubuntu package maintainers have already picked this up. From an upstream OpenStack perspective, we don't mandate use of vulnerable versions of dependencies, as the suggested version ranges in the requirements.txt you linked can confirm.

[Jeremy Stanley (fungi)]

Reviewing the various links included in the bug description, I expect the one which may cause the greatest challenge to address is CVE-2015-9251 for jQuery, as they rolled back the 1.x fix for backward incompatibilities and then released it as 3.0.0 instead, but Horizon's requirements include an upper bound of <2 at the moment. However, reading the description and discussion of that vulnerability, the jQuery maintainers seemed to consider it low severity and impractical to exploit in most applications, requiring something like a `$.get(untrusted_url)` in order to reach the bug at all. It's not readily apparent that ever happens the way jQuery is used in Horizon, so likely irrelevant, but the discussion also includes code we could apply upstream as a workaround if we're unable to make Horizon work with jQuery 3.x: https://github.com/jquery/jquery/issues/2432#issuecomment-403761229

[Jeremy Stanley (fungi)]

In https://review.opendev.org/771577 I see indication the Horizon team plans to remove that <2 cap for XStatic-jQuery, and seems to think it should work, but that does not seem to have happened yet.

[Corey Bryant (corey.bryant)]

I checked the Ubuntu code, assuming the scanned code is all in /usr/lib/python3/dist-packages/horizon/xstatic/, here are my findings. I haven't assessed whether the code is actually vulnerable from the horizon dashboard.

## jQuery 1.12.4

This appears to be patched in focal:

ubuntu@juju-e9cc66-zaza-906d385905ca-7:/usr/lib/python3/dist-packages/horizon/xstatic$ grep -r -A 5 2432
pkg/angular/data/angular-scenario.js:// Prevent auto-execution of scripts when no explicit dataType was provided (See gh-2432)
pkg/angular/data/angular-scenario.js-jQuery.ajaxPrefilter( function( s ) {
pkg/angular/data/angular-scenario.js- if ( s.crossDomain ) {
pkg/angular/data/angular-scenario.js- s.contents.script = false;
pkg/angular/data/angular-scenario.js- }
pkg/angular/data/angular-scenario.js-} );

## jQuery Migrate 1.2.1

This appears to be patched in focal:

ubuntu@juju-e9cc66-zaza-906d385905ca-7:/usr/lib/python3/dist-packages/horizon/xstatic$ grep -r -A 2 'Strict HTML'
pkg/jquery/data/jquery.js: // Strict HTML recognition (#11290: must start with <)
pkg/jquery/data/jquery.js- rquickExpr = /^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]*))$/,
pkg/jquery/data/jquery.js-
--
pkg/angular/data/angular-scenario.js: // Strict HTML recognition (#11290: must start with <)
pkg/angular/data/angular-scenario.js- // Shortcut simple #id case for speed
pkg/angular/data/angular-scenario.js- rquickExpr = /^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]+))$/,

## AngularJS 1.5.8

This appears to be unpatched in all Ubuntu and upstream releases, see the following files:

/usr/lib/python3/dist-packages/horizon/xstatic/pkg/angular/data/angular.js
/usr/lib/python3/dist-packages/horizon/xstatic/pkg/angular/data/angular-scenario.js

This is fixed upstream in 1.8.2.0 of https://opendev.org/openstack/xstatic-angular, however
upper-constraints for stable/ussuri->master are still limited to 1.5.8.0 [1], which doesn't
have the fix.

[1]
https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L95
https://github.com/openstack/requirements/blob/stable/ussuri/upper-constraints.txt#L169

[Corey Bryant (corey.bryant)]

Jeremy, it looks like the AngularJS 1.5.8 issue is patched in 1.8.2.0 of https://opendev.org/openstack/xstatic-angular but upper-constraints hasn't picked that version up yet (links are in my previous comment above). I wonder if we can get master u-c to 1.8.2.0, and get the fix cherry-picked/released with a 1.5.8.1, and move other supported stable branches u-c to 1.5.8.1.

[Jeremy Stanley (fungi)]

After more digging than I'd hoped to do, I see that the Horizon team has been trying to update the xstatic-angular constraint in the master branch for 6 months. Help is probably needed to more urgently drive https://review.opendev.org/794258 to conclusion.

As for backporting patches to a stable branch of the openstack/xstatic-angular repository, I expect that should be possible but am unsure whether it's been done with any of the other xstatic-* packages in the past.

Input from Horizon's core security reviewers could be helpful on both these points, so I've subscribed them to the report.

[Seth Arnold (seth-arnold)]

Jeremy, is there any need for this bug report to remain private? On a quick read I don't see anything that looks sensitive.

Thanks

[Jeremy Stanley (fungi)]

Seth: Since OpenStack isn't treating this as an upstream bug, I was leaving it up to the Ubuntu package maintainers to decide if they wanted it kept private. I have no objections to making it public immediately.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Balazs Gibizer (balazs-gibizer)]

https://bugs.launchpad.net/horizon/+bug/1960489 got duplicated to this bug. In that bug I listed 4 CVEs where, based on the CVE description, the issues only fixed in JQuery >= 3 (and 3.5 in some cases). This bug is marked as Invalid from upstream perspective stating that "From an upstream OpenStack perspective, we don't mandate use of vulnerable versions of dependencies, as the suggested version ranges in the requirements.txt you linked can confirm." But upstream Horizon do states JQuery < 2 which means we do mandate impacted JQuery versions. I'm marking this as New again to get attention to this new fact.

[Jeremy Stanley (fungi)]

Is bug 1914782 what's currently holding back the jQuery v3 work?

[Jeremy Stanley (fungi)]

Balazs Gibizer: It's a grey area, but it's technically correct to say that we don't mandate use of vulnerable jQuery. Our global requirements and constraints lists indicate the upstream versions we test with and know to work, which yes are vulnerable versions. OpenStack expects security vulnerabilities in its dependencies to be patched downstream in most cases (GNU/Linux distributions often backport security fixes to older versions of libraries).

If Horizon developers have time to get it working and tested with newer libraries rather than putting the dependency patching burden on downstream consumers, then that would be great, of course, but it's unlikely to be a backportable solution in Horizon so not something we're going to be able to issue a security advisory for (hence the "won't fix" state for the advisory task). Hopefully that makes sense?

[Balazs Gibizer (balazs-gibizer)]

OK, so the general answer is that we expect downstream to fix the CVEs in the dependencies. We only focus on direct vulnerabilities in Horizon.
Fine by me. Thanks Jeremy.

[Jeremy Stanley (fungi)]

Basically, yes. Horizon contributors generally can't fix a vulnerability *in* jQuery, though they may sometimes be able to implement a workaround for one in order to avoid exposing that vulnerability to users. Horizon contributors can, given available time and inspiration, make the software work with a newer version of jQuery which includes a fix for that vulnerability, but because we freeze dependency versions at release time that wouldn't be backportable (it's still a good thing to do, of course).