Re: pulling in other vulnerability databases
On Thu, Jan 25, 2018 at 1:12 AM, Antoine Beaupré wrote: > Okay, so this is a broader, recurring problem we have with the security > tracker right now... From my perspective, I've always and only used CVEs > as unique identifiers for vulnerabilities in my work in the security > tracker. When that was not possible, say because a CVE wasn't issued > yet, CVE-- templates were used, which leads to ugly TMP-FOO > markers in the web interface. That is how things are supposed to work indeed. > Are you saying there are ways, right now, in the security tracker, to > use non-CVE identifiers as unique markers in a meaningful way? Not AFAIK. I think that having non-CVE identifiers on hand is a useful but secondary goal. Achieving the primary goal also makes it easier to achieve this too. I'm mainly pointing out we need better automated ingestion of vulnerability data for multiple reasons: Mitre is *very* slow at unrestricting CVE information after a project has published advisories, just look in CVE/list for things that are still RESERVED but we have data for. There are more vulnerability databases than just CVEs and this problem is not going to go away. Some of these may (partially) overlap with the CVE database. The manual ingestion of vulnerability information into the security tracker currently falls mainly on just one person (carnil). Having just one person do all of that work isn't fair on them and does not scale. If we automate more ingestion then there will be less latency and he will have less work to do and be able to focus more on other things like vulnerability feeds that aren't automatable (like mailing lists). > we discussed using BTS bug numbers in the past, but right now > those are, as far as I know, bound to entries in data/CVE/list only. Correct. > Where should we start to implement the above? Any pointers to where a > Python dev might look in the security-tracker source to actually work on > this? It seems this would also affect the DSA/DLA release process - i > think it *is* possible to actually release a CVE-less DSA right now, but > I wonder if the process would stall in other places... First we should decide if we want non-CVE identifiers and define how we want to represent non-CVE identifiers in data/CVE/list. I would go for yes and something like this: CVE-2017-17565 (An issue was discovered in Xen through ...) ... ID: XSA-251 Next the database would need an additional identifier mapping table. The CVE page could then also list XSA-251 in the Name field, linked to the canonical location for XSAs. The search field could be used to lookup XSAs and redirect to the right CVE page, just like we do for BTS entries. After that I'm not sure, but I think I would look at how the 'automatic updates' commits happen and then extend that process to include other types of data feeds than just the CVE one. I started a list of possible feeds in check-external/sources.ini I think the GSoC or Outreachy would be an ideal way to achieve this and wrote a proposal a couple of years ago, but couldn't find anyone interested in mentoring it. ISTR last time I brought up this idea it was dismissed as a bad idea. https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal > And are we admitting here that we should just give up on the CVE process > in those cases? Or should we make an effort (say like we do in reporting > bugs against packages in teh BTS) to actively seek CVE identifiers for > vulnerabilities that lack them, like I did for the jquery issues? I don't think it is a good idea to give up on the CVE process and I think doing so would be a violation of the Debian Social Contract. In my opinion it would be a good idea (modulo workload issues) to seek CVE identifiers for vulnerabilities reported in all vulnerability databases, just like is done for the BTS (tag=security is kind of a vuln db) and other locations. > Sorry to bring so many questions and so few answers, but I figured it is > useful to actually scope out the problem better before starting an > implementation. :) Quite. -- bye, pabs https://wiki.debian.org/PaulWise
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
pulling in other vulnerability databases
So picking one thing from this thread and adding the security tracker people in the loop, so we can focus on *one* topic here. :) On 2018-01-21 14:09:01, Paul Wise wrote: > On Fri, Jan 19, 2018 at 11:52 PM, Antoine Beaupré wrote: > >> I have found that Snyk had issues in its database that weren't in Mitre: >> >> https://snyk.io/vuln/npm:jquery > > I note that nodesecurity also has some CVE-less issues: > > https://nodesecurity.io/advisories?search=jquery > >> 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? > > I would guess there are a lot of different vuln databases out there: > > Competition for Mitre & CVEs (Snyk) > Language communities (NodeSecurity) > OS vendors (RH/SUSE) > Upstream projects (Xen, Linux etc) > Security community (oss-sec, fulldisclosure, conferences etc) > > Each of them have their own identifiers and possibly also link to CVEs. > > I'd suggest we need (semi-)automated ingestion of all of the above, > like we currently have for CVEs. Okay, so this is a broader, recurring problem we have with the security tracker right now... From my perspective, I've always and only used CVEs as unique identifiers for vulnerabilities in my work in the security tracker. When that was not possible, say because a CVE wasn't issued yet, CVE-- templates were used, which leads to ugly TMP-FOO markers in the web interface. Are you saying there are ways, right now, in the security tracker, to use non-CVE identifiers as unique markers in a meaningful way? I remember we discussed using BTS bug numbers in the past, but right now those are, as far as I know, bound to entries in data/CVE/list only. Where should we start to implement the above? Any pointers to where a Python dev might look in the security-tracker source to actually work on this? It seems this would also affect the DSA/DLA release process - i think it *is* possible to actually release a CVE-less DSA right now, but I wonder if the process would stall in other places... And are we admitting here that we should just give up on the CVE process in those cases? Or should we make an effort (say like we do in reporting bugs against packages in teh BTS) to actively seek CVE identifiers for vulnerabilities that lack them, like I did for the jquery issues? Sorry to bring so many questions and so few answers, but I figured it is useful to actually scope out the problem better before starting an implementation. :) A. -- Il n'existe aucune limite sacrée ou non à l'action de l'homme dans l'univers. Depuis nos origines nous avons le choix: être aveuglé par la vérité ou coudre nos paupières. - [no one is innocent]
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 01/24/2018 08:02 AM, Moritz Mühlenhoff wrote: On Tue, Jan 23, 2018 at 11:41:57AM +0100, Lars Tangvald wrote: I can't find much of anything that has changed from 5.5 to 5.6 in terms of default behavior, except for NO_ENGINE_SUBSTITUTION being the default sql_mode (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). I'll do some more digging, but I don't think there should be much impact on reverse-dependencies. Some options were removed https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often renamed). We did see quite a few regressions of that type for users upgrading from 5.5 to 5.7, but almost all were because the default 5.5 config in Ubuntu packaging contained options that were removed in 5.7. That sounds far too disruptive for an LTS; better declare announce the server part of mysql (where all the vulnerabilities apply) as unsupported in advance and in December change the package to only build the libmysqlclient parts. The client library part is usually not affected by any security issues and that way you don't risk any regressions. Usually, yes, but what happens when this is not the case? Keep in mind that the issues we got reported in Ubuntu was because the removed options were in the 5.5 default config file shipped in Ubuntu. There's no such settings in the 5.5 to 5.6 upgrade. People then have a year to migrate their servers to jessie (or ideally update/reimage to stretch) This is about Jessie, which currently has 5.5. -- Lars Cheers, Moritz
