cvescan fails to report on (at least a set of kernel) security updates about sec-cvescan

[kikoreis]

Note that the list above only shows the upgradable metapackages; the actual binaries aren't listed because due to how kernel package naming works (embedding versions) they are actually new packages, not upgrades. I wonder if that's related to this cvescan issue.

[kikoreis]

The hint that lead ot the conclusion above was that motd correctly reports:

ubuntu@ip-172-31-29-146:~$ grep security /var/run/motd.dynamic 
7 updates are security updates.

The reason it knows is because /usr/lib/update-notifier/apt-check loops through everything which is marked either install or upgrade, i.e.:

            if not (depcache.marked_install(pkg) or
                    depcache.marked_upgrade(pkg)):
                continue

Whereas a simple apt list --upgradable | grep security won't list packages marked for installation.

[markmorlino]

I think this might be a problem with the OVAL generation rather than with cvescan.

ubuntu@ip-172-31-29-146:~$ grep 4.15.0.1063.64 /home/ubuntu/snap/cvescan/common/com.ubuntu.bionic.cve.oval.xml

And it might be related to the known problem we have where the OVAL uses the source package version (even in cases where the inary packages generated from that source have different version strings)

[markmorlino]

The OVAL is saying that it is fixed in a different version

ubuntu@ip-172-31-29-146:~$ grep linux-aws /home/ubuntu/snap/cvescan/common/com.ubuntu.bionic.cve.oval.xml| grep test_ref | grep 1063 | head -n 1
<criterion test_ref="oval:com.ubuntu.bionic:tst:2019152170000010" comment="linux-aws package in bionic was vulnerable but has been fixed (note: '4.15.0-1063.67')." />

[Edited to make the result of the grep visible, github was filtering it -- stevebeattie]

[stevebeattie]

Yes. Kernel's are particularly difficult to track because the meta packages that get updates in generated from a separate source package (linux-meta-aws in this case) from the actual source package that provides the binary packages (source linux-aws), and thus contains the actual fix. It gets even more complicated if signed kernels are used, because they are from a third source package (linux-signed-DERIVATIVE, would be linux-signed-aws on amd64 here).

In this case, the version @markmorlino is seeing above is the actual version of the linux-aws source package; but that differs from the version of the meta source package.

The oval does define:

        <linux-def:dpkginfo_object id="oval:com.ubuntu.bionic:obj:201245420000010" version="1" comment="The 'linux-aws' package binary.">
            <linux-def:name>linux-image-4.15.0-1063-aws</linux-def:name>
        </linux-def:dpkginfo_object\>

but that test object is not the one that is getting applied for the specific issues address by the 1063 kernel (though to be fair I haven't looked terribly closely at the xml).

[stevebeattie]

Oh right, this is the test referenced above:

        <linux-def:dpkginfo_test id="oval:com.ubuntu.bionic:tst:2019152170000010" version="1" check_existence="at_least_one_exists" check="at least one" comment="Does the 'linux-aws' package exist and is the version less than '4.15.0-1063.67'?">
            <linux-def:object object_ref="oval:com.ubuntu.bionic:obj:201245420000010"/>
        <linux-def:state state_ref="oval:com.ubuntu.bionic:ste:2019152170000010" />
        </linux-def:dpkginfo_test>

which checks the object oval:com.ubuntu.bionic:obj:201245420000010:

        <linux-def:dpkginfo_object id="oval:com.ubuntu.bionic:obj:201245420000010" version="1" comment="The 'linux-aws' package binary.">                    
            <linux-def:name>linux-image-4.15.0-1063-aws</linux-def:name>                                                                                     
        </linux-def:dpkginfo_object\>                                                                                                                        

in this case, the linux-image-4.15.0-1063-aws kernel package against the version 4.15.0-1063.67:

        <linux-def:dpkginfo_state id="oval:com.ubuntu.bionic:ste:2019152170000010" version="1" comment="The package version is less than '4.15.0-1063.67'.">
            <linux-def:evr datatype="debian_evr_string" operation="less than">4.15.0-1063.67</linux-def:evr>
        </linux-def:dpkginfo_state>

[stevebeattie]

But yes, what I believe (not having looked at the oval generator code) needs to happen as well is for it to lookup in launchpad what the specific matching abi version is for the associated meta package, and include a correct version test for that.

[markmorlino]

I think that explains why those are not being reported by cvescan. And the other discrepancy comes from update notifier showing both security packages that will be updated and packages that will be newly installed on the system but already have security updates. The latter won't be reported by cvescan since they are not installed yet.