Javascript libraries with vulnerabilities

Bug #1955556 reported by Stephan Pampel
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Confirmed
High
Unassigned
OpenStack Security Advisory
Won't Fix
Undecided
Unassigned
horizon (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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?

CVE References

Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Changed in horizon:
status: New → Invalid
Changed in ossa:
status: New → Won't Fix
Revision history for this message
Jeremy Stanley (fungi) wrote :

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

Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Revision history for this message
Corey Bryant (corey.bryant) wrote (last edit ):

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

Revision history for this message
Corey Bryant (corey.bryant) wrote (last edit ):

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.

Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

information type: Private Security → Public
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in horizon (Ubuntu):
status: New → Confirmed
Revision history for this message
Balazs Gibizer (balazs-gibizer) wrote :

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.

Changed in horizon:
status: Invalid → New
Changed in horizon:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Jeremy Stanley (fungi) wrote :

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

Revision history for this message
Jeremy Stanley (fungi) wrote :

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?

Revision history for this message
Balazs Gibizer (balazs-gibizer) wrote :

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.

Revision history for this message
Jeremy Stanley (fungi) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.