jquery CVEs: no-dsa or unsupported? + snyk.io
Hi!
As part of an audit on my own website (!) running Bootstrap 3.3.4, I
have found that the jQuery release I was using (1.11.2) was vulnerable
to multiple security issues. This was detected by Sonarwhal, which in
turns uses Snyk.io to make such security assesments. Tracking that down,
I have found that Snyk had issues in its database that weren't in Mitre:
https://snyk.io/vuln/npm:jquery
So I went ahead and requested 3 CVEs for mitre to cover for those, which
are now followed in the security tracker (CVE-2012-6708, CVE-2015-9251
and CVE-2016-10707).
Turns out that CVE-2016-10707 was introduced only during the release of
3.0, so no stable release was affected: this was a mistake in the Snyk
database. So that's solved as far as Debian's concerned.
The other two fixes are invasive: one requires refactoring, which
upstream has abandoned, in favor of the 3.0 release. The other required
releasing 1.9 to break backwards compatibility. In both cases, it
doesn't seem to be reasonable to produce a fix without producing major
breakage. I haven't done full scoping of the issues: XSS is of course a
terrible gateway drug that we should pay close attention to, like any
other disclosure issue...
I would be tempted to mark those issues as no-dsa, but then we should
probably warn our users that those older jQuery releases are just not
supported... that is really the situation right now and pretending
otherwise will just hurt everyone. Maybe an update to the
debian-security-support package for any release prior to stretch?
Otherwise people should feel free to inspect the patches and see what
could be possible, but I strongly doubt meaningful fixes could be
applied to 1.7.x. If it's any consolation, jQuery uses a more stable
release schedule now, bound to semver. It should be fairly safe to
update between major/patch releases if we really need to: the last
non-major breakage was 1.9, from what I can tell so, once we're past
that point, we can update between any points on a major scale without
causing disruption. This means, for example, we could probably update
from stretch's 3.1 release to buster 3.2 if there's no easy fix for
stretch available, without causing compatibility issues for our users.
Finally, I wanted to bring Snyk.io to the teams' attention. I'm a little
disturbed by that new service - I feel there's significant overlap
between their vulnerability reporting process and Mitre's DWF/DNA
process, even down to using Google forms to welcome submissions, in the
case of DWF (!!). The Snyk (closed) database tracks vulnerabilities in
web apps, mostly, covering the following languages: Golang, Java
(maven), Javascript (npm), .NET (nuget), PHP (composer), Python (pip),
and Ruby (rubygems). I haven't done a formal study, but a quick glance
at the latest issues show that only a small fraction of the issues
reported there have CVE IDs at all.
This connects with the question of how to track issues without CVEs. In
general, that is a problem we have in the security tracker because it's
so bound to CVE identifiers. But this is a new problem as well: by
opening a new process for submitting vulnerabilities, this system
potentially bypasses the CVE system altogether, using a
commercial/proprietary backend. I am worried about the impact this will
have on our triaging efforts and wonder where we should go from here.
Food for thought?
A.
--
The destiny of Earthseed is to take root among the stars.
- Octavia Butler
Reply to: