Re: jquery CVEs: no-dsa or unsupported?
On 2018-01-19 10:52:05, Antoine Beaupré wrote:
> 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.
It's been a few days since I wrote this report. Anyone took a look at
that? I see the jquery issues still need triage in wheezy and jessie,
what is our take on this?
Thinking back, marking jquery as unsupported is not really feasible as
there is a huge number of reverse dependencies, e.g. on stretch:
$ LANG=C apt rdepends libjs-jquery | grep Depends | wc -l
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
970
On wheezy it's ... not as bad, but still:
$ LANG=C chdist apt wheezy rdepends libjs-jquery | grep Depends | wc -l
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
266
Some of those include LTS-sponsored packages like cacti...
Ideas?
A.
--
The secret of life is to have no fear; it's the only way to function.
- Stokely Carmichael
Reply to: