7515 2015-03-25 15:22:06 +0000 Add CVE testing tool 2017-02-07 09:12:02 +0000 1 1 6 Yocto Project Subprojects Patchwork/Patchtest Patchtest Testsuite unspecified All Multiple RESOLVED FIXED https://bugzilla.yoctoproject.org/show_bug.cgi?id=10771 Medium+ enhancement 2.2 M4 8119 1 ross.burton mariano.lopez akuster alex.kanavin bluelightning jose.a.lamego joshuagloe leonardo.sandoval.gonzalez mariano.lopez mhalstead richard.purdie stanciux.mihail zhenfeng.zhao georgex.l.musat --- --- No (bug/feature does not impact docs) oldest_to_newest 49752 0 ross.burton 2015-03-25 15:22:06 +0000 Clear Linux has released their CVE checking tool (https://github.com/ikeydoherty/cve-check-tool) which verifies that all known CVEs are fixed in their distribution. We should extend that tool to read bitbake metadata. 49808 1 sgw 2015-03-26 16:09:17 +0000 Please also refer to our existing tool: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mulhern/cvechecker-final2, which uses an upstream tool and set of scripts in the 3rd commit from the top. We want to consider integrating this in with recipetool and AUH. This may be something given to one of the othe GDC, but leaving with Anibal as starting point. 50363 2 ross.burton 2015-04-16 17:03:57 +0000 The author of the Clear tool isn't very complementary of the upstream tool. Integration into other tooling such as AUH is useful but the ability to run standalone is fairly important I'd say: the ability to run a full CVE check when you're getting ready to release is key. 50731 3 alexandru.c.georgescu 2015-05-04 11:15:39 +0000 Lucian, Maybe we can dry run this before it's implemented by Ross. 52885 4 anibal.limon 2015-08-06 20:19:47 +0000 Talking with RP it have a dependency in upstream patching format that need to specify if patch is CVE. 55952 5 akuster 2015-10-28 21:16:39 +0000 What is the intent of such a framework or tool? What will the Yocto Project do with the data is gathers from such a tool? Is the AB ok with the Yocto project exposing security vulnerabilities to AB member customers before the AB members can get their responses / fixes distributed? Or the AB member customers may not approve if they them selves can get the fixes in their products. - Armin 55953 6 akuster 2015-10-28 22:22:44 +0000 I have been avoiding commenting on this as I was hoping an unbiased individual would have run this to see what it takes to accurately get a listing of vulnerabilities. I have not run this myself but the description is similar in nature to OpenVas which I have run. They both need databases to be able to provide notification if a package is vulnerable. The first issue is the data provided in security notifications are not always accurate. A common statement is Version X and below are affected. Now someone needs to look at the code to see if this is true. Kernel tends to be worst offender in this. Who has the time to do this? So we use the prserver.. all packages are 'R0' and we don't rev no mater how many security patches have been applied. If the scanning s/w is run, it will produce false positives. Do we update the DB? Or a copy of the prserve data needs to be provided and synced with a commit so to minimize false positives. any false positives need to be updated in the database. Who has the time to do this? This comparison tends to works if the package itself is updated to a newer version. I would rather spend the time fixing something than creating and maintaining a database to tell me something is possible affected. 56148 7 ross.burton 2015-11-03 16:24:21 +0000 As far as a tool goes, we've recently open-sourced something that was being developed privately by a sister team: https://github.com/01org/isafw It's a framework of security-related tools but the relevant bit for this is ISA_cve_plugin which uses cve-check-tools (https://github.com/ikeydoherty/cve-check-tool) for the real work. I'm building this now to see how well it works. 56149 8 ross.burton 2015-11-03 16:33:20 +0000 Erm, make that https://github.com/01org/meta-security-isafw for the layer. 56150 9 anibal.limon 2015-11-03 16:46:22 +0000 (In reply to comment #8) > Erm, make that https://github.com/01org/meta-security-isafw for the layer. I tried to use the layer but fails when try to INHERIT, Traceback (most recent call last): File "/home/alimon/repos/poky/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include(parentfn='configuration INHERITs', fn='classes/isafw.bbclass', lineno=0, data=<bb.data_smart.DataSmart object at 0x7f0f426eb950>, error_out='inherit'): if error_out: > raise ParseError("Could not %s file %s" % (error_out, fn), parentfn, lineno) logger.debug(2, "CONF file '%s' not found", fn) ParseError: ParseError in configuration INHERITs: Could not inherit file classes/isafw.bbclass 56153 10 ross.burton 2015-11-03 17:59:23 +0000 Anibal, did you add the layer to bblayers.conf? 56154 11 anibal.limon 2015-11-03 18:08:41 +0000 (In reply to comment #10) > Anibal, did you add the layer to bblayers.conf? Yes, without it in bblayers.conf don't fail. 56156 12 ross.burton 2015-11-03 18:29:42 +0000 As an experiment into using cve-check-tool without the isafw surrounding it I wrote a ten-line python class and added it to meta-ross (github:rossburton/meta-ross). With current jethro against core-image-sato I get this: WARNING: iptables: Unpatched CVEs: CVE-2012-2663 WARNING: readline: Unpatched CVEs: CVE-2014-2524 WARNING: expat: Unpatched CVEs: CVE-2013-0340 WARNING: subversion: Unpatched CVEs: CVE-2015-3184 CVE-2015-3187 WARNING: vte: Unpatched CVEs: CVE-2012-2738 WARNING: iptables: Unpatched CVEs: CVE-2012-2663 WARNING: unzip: Unpatched CVEs: CVE-2014-9636 WARNING: expat: Unpatched CVEs: CVE-2013-0340 WARNING: expat: Unpatched CVEs: CVE-2013-0340 WARNING: readline: Unpatched CVEs: CVE-2014-2524 WARNING: qemu: Unpatched CVEs: CVE-2015-5279 WARNING: readline: Unpatched CVEs: CVE-2014-2524 Doubtless there's recipes missed due to PN mismatch (I'm thinking gcc) and false-positives from bad patch names (libarchive is fixed in my local branch, should be reporting there) but this is an interesting start. I don't see any problems with using something like this on release branches, as long as CVE patches have the CVE ID in the filename. I guess an important question is do we a) endorse meta-security-isafw or b) split out the bits we like into something more focused in oe-core. 56158 13 akuster 2015-11-03 20:07:52 +0000 (In reply to comment #12) > As an experiment into using cve-check-tool without the isafw surrounding it > I wrote a ten-line python class and added it to meta-ross > (github:rossburton/meta-ross). With current jethro against core-image-sato > I get this: > > WARNING: iptables: Unpatched CVEs: CVE-2012-2663 > WARNING: readline: Unpatched CVEs: CVE-2014-2524 > WARNING: expat: Unpatched CVEs: CVE-2013-0340 > WARNING: subversion: Unpatched CVEs: CVE-2015-3184 CVE-2015-3187 > WARNING: vte: Unpatched CVEs: CVE-2012-2738 > WARNING: iptables: Unpatched CVEs: CVE-2012-2663 > WARNING: unzip: Unpatched CVEs: CVE-2014-9636 > WARNING: expat: Unpatched CVEs: CVE-2013-0340 > WARNING: expat: Unpatched CVEs: CVE-2013-0340 > WARNING: readline: Unpatched CVEs: CVE-2014-2524 > WARNING: qemu: Unpatched CVEs: CVE-2015-5279 > WARNING: readline: Unpatched CVEs: CVE-2014-2524 Does it queue the kernel? its missing the libxml2 and libxslt. (patches in queue for libxslt) > > Doubtless there's recipes missed due to PN mismatch (I'm thinking gcc) and > false-positives from bad patch names (libarchive is fixed in my local > branch, should be reporting there) but this is an interesting start. I > don't see any problems with using something like this on release branches, Ask Fray.. he had concerns. > as long as CVE patches have the CVE ID in the filename. kernel wont. > > I guess an important question is do we a) endorse meta-security-isafw or b) > split out the bits we like into something more focused in oe-core. why would we want another security layer? there are 4 currently 57164 14 stanciux.mihail 2015-12-10 13:51:57 +0000 (In reply to comment #3) > Lucian, > Maybe we can dry run this before it's implemented by Ross. I've added a buildstep on our local AB that runs the cve-check-tool against a nightly-world build and sends and email with the results. For now it sends the e-mail just to me until I'm sure everything is working properly. 57280 15 mariano.lopez 2015-12-15 16:08:02 +0000 I started a RFC thread in OE-core, OE-devel, so we get more input. Feel free to comment. http://lists.openembedded.org/pipermail/openembedded-core/2015-December/114166.html http://lists.openembedded.org/pipermail/openembedded-core/2015-December/114166.html 57488 16 mariano.lopez 2015-12-29 20:24:02 +0000 Will wait after the holidays to reach a conclusion 57502 17 ross.burton 2016-01-04 11:28:33 +0000 WaitForUpstream is only valid if there's an upstream and generally means a bug disappears forever. Changing back to accepted now the holiday is over. :) 59291 18 mariano.lopez 2016-02-19 22:38:43 +0000 I have started to implement this class using cve-check-tool base on Ross' class 59301 19 akuster 2016-02-19 23:17:47 +0000 (In reply to comment #18) > I have started to implement this class using cve-check-tool base on Ross' > class Please answer my questions in commit #5. in addition. where will this class reside? 59471 20 mariano.lopez 2016-02-25 17:20:42 +0000 The idea is just to provide the tool, what people do with is up to them. I don't think we are going to expose the vulnerabilities more than they already exposed. For example, you can download the layer that Ross mentioned and get what CVEs haven't been patched. The idea is to include the tool into oe-core 59482 21 akuster 2016-02-25 21:51:30 +0000 (In reply to comment #20) > The idea is just to provide the tool, what people do with is up to them. > > I don't think we are going to expose the vulnerabilities more than they > already exposed. For example, you can download the layer that Ross mentioned > and get what CVEs haven't been patched. > > The idea is to include the tool into oe-core thanks for the reply 59527 22 mariano.lopez 2016-02-29 14:43:45 +0000 Sent patches to the list: http://lists.openembedded.org/pipermail/openembedded-core/2016-February/118117.html 59813 23 mariano.lopez 2016-03-08 22:30:19 +0000 Moving to 2.2, this enhancement didn't make it to 2.1 66308 24 ross.burton 2016-09-19 12:41:37 +0000 Merged in oe-core d98338075ec3a66acb8828e74711550d53b4d91b.