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
