Bug 10772

Unfortunately it seems cve-check-tool development has stopped, we need to check what other options do we have.

(In reply to comment #1)
> Unfortunately it seems cve-check-tool development has stopped, we need to
> check what other options do we have.

Do you mean the upstream github repo that is sponsored by Intel and Intel no longer is interested in developing it any further?
Last commit was a month ago.

I've emailed the author to get a definitive answer on whether it's maintained or if there's an alternative, but he's been on leave.

2.3M4 is basically over, so moving to next milestone. Also, pending on maintainer's answer to define direction.

Per Ross recommendation, setting 2.4 as milestone.

Ross,
do you have any update from the maintainer?

I think cve-check tool works fine. When building the core images a cve report is generated if cve-check tool is enabled:

tmp/deploy/images/qemux86/core-image-minimal-emux86-20170816072229.rootfs.cve

I always inherit the cve-check class when I build an image and check the result.
It would be good to schedule autobuilder to generate this report once in a while and save the report somewhere. We could then add the link to the Yocto security wiki.

(In reply to comment #7)
> I think cve-check tool works fine. When building the core images a cve
> report is generated if cve-check tool is enabled:
> 
> tmp/deploy/images/qemux86/core-image-minimal-emux86-20170816072229.rootfs.cve
> 
> I always inherit the cve-check class when I build an image and check the
> result.
> It would be good to schedule autobuilder to generate this report once in a
> while and save the report somewhere. We could then add the link to the Yocto
> security wiki.

But can you trust what this tool generates? 

I have just tested now to build core-image-lsb from poky (branch pyro) and I included on the image the "sudo" recipe, which is still on version 1.8.19p2 and therefore affected by CVE-2017-1000367 <https://www.sudo.ws/alerts/linux_tty.html> 

I inherited cve-check and I simply got a file named core-image-lsb-genericx86-64.cve which simply contains "CVE database was updated on 2017-08-16 11:27:43 UTC" and nothing else.

Created attachment 3945 [details]
core-image-minimal-qemux86.cve

> But can you trust what this tool generates? 

No I can't trust 100% , but this is another issue :) The tool however detects some unpatched CVEs without big efforts (see the attached core-image-minimal-qemux86.cve file). We could start fixing them ...

We can of course try always to improve existing tools or replcae with better tools if available.

(In reply to comment #9)
> Created attachment 3945 [details]
> core-image-minimal-qemux86.cve

Mmmmm.. it looks its not working for me at all as I don't get this.

Do I need to do something else than just setting "inherit cve-check" on the image recipe? Do i need to set something on local.conf ?

I think for some recipes you will need set CVE_PRODUCT, for example tiff.bb sets CVE_PRODUCT=libtiff, provided that the recipe name does not match the name in CVE database.

(In reply to comment #11)
> (In reply to comment #9)
> > Created attachment 3945 [details]
> > core-image-minimal-qemux86.cve
> 
> Mmmmm.. it looks its not working for me at all as I don't get this.
> 
> Do I need to do something else than just setting "inherit cve-check" on the
> image recipe? Do i need to set something on local.conf ?

I just tried it. I add to my local.conf

inherit += "cve-check"

bitbake -k -c cve_check universe

should get you started.

Created attachment 3946 [details]
cve-checktool - Master

Here are the current failures in master.

(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > Created attachment 3945 [details]
> > > core-image-minimal-qemux86.cve
> > 
> > Mmmmm.. it looks its not working for me at all as I don't get this.
> > 
> > Do I need to do something else than just setting "inherit cve-check" on the
> > image recipe? Do i need to set something on local.conf ?
> 
> I just tried it. I add to my local.conf
> 
> inherit += "cve-check"
> 

This didn't worked for me. But adding instead to local.conf the line below worked:

INHERIT_append = " cve-check"



Quick example:

On branch pyro, with inherit += "cve-check" on local.conf I get:
$ bitbake -c cve_check avahi
[...]
ERROR: Task do_cve_check does not exist for target avahi /home/igalia/clopez/[...]/poky/meta/recipes-connectivity/avahi/avahi_0.6.32.bb:do_cve_check)
ERROR: Command execution failed: 1


But with INHERIT_append = " cve-check" on local.conf I get:
$ bitbake -c cve_check avahi
[...]
WARNING: avahi-0.6.32-r0 do_cve_check: Found unpatched CVE (CVE-2017-6519), for more information check /home/igalia/clopez/[...]/avahi/0.6.32-r0/cve/cve.log

I add following line in conf/local.conf file: 

INHERIT += "cve-check"

and run: 
#   bitbake -c cve_check openssl 
#   bitbake core-image-sato
#   bitbake -k -c cve_check universe

This always work for me :)

Moving out of needinfo.  cve-check-tool is mostly abandoned but whilst we still have it in oe-core, it's the best we've got.

(In reply to comment #17)
> Moving out of needinfo.  cve-check-tool is mostly abandoned but whilst we
> still have it in oe-core, it's the best we've got.

I will fork it and see where that leads me too ; )

(In reply to comment #17)
> Moving out of needinfo.  cve-check-tool is mostly abandoned but whilst we
> still have it in oe-core, it's the best we've got.

Agreed.
I also think this is more than enough to start improving the quality of the Yocto releases in terms of security fixes.

I enabled it and it is reported dozens of unfixed CVEs on last stable (pyro).

Is there any plan to start fixing this issues reported on the next Yocto release? Could deploying a buildbot at https://autobuilder.yoctoproject.org/main/ that runs cve_check over universe be of help? Just an idea.

(In reply to comment #19)
> (In reply to comment #17)
> > Moving out of needinfo.  cve-check-tool is mostly abandoned but whilst we
> > still have it in oe-core, it's the best we've got.
> 
> Agreed.
> I also think this is more than enough to start improving the quality of the
> Yocto releases in terms of security fixes.
> 
> I enabled it and it is reported dozens of unfixed CVEs on last stable (pyro).

Does not surprise me. What are your expectations?

> 
> Is there any plan to start fixing this issues reported on the next Yocto
> release?

The plan is to fix what folks submit. Yocto is not a commercial distro and does not have the funds nor resources to do everything. We rely heavily on the community to help. You are welcome to submit package updates or patches to address individual security vulnerabilities.

 Could deploying a buildbot at
> https://autobuilder.yoctoproject.org/main/ that runs cve_check over universe
> be of help? Just an idea.

There is a bug open for this but it at best will only highlight what is missing to the best the tools ability. It will still come down to folks doing the work to fix them.

we can use OVAL files with runs on a target. openscap will create html reports. 
not sure about cve-chektool

We have tooling to generate the reports, but I don't think that OE/Yocto should be advertising what exploits are in the metadata.