designated object in OVAL definition may be wrong

[Hombre]

recently published OVAL definition (https://people.canonical.com/~ubuntu-security/oval/) may have some breaking change as following:

all definition which referenced 'linux' binary package object, has been affected.

How to reproduce:
for example find definition id: oval:com.ubuntu.xenial:def:2019114770000000
then in criterions find test_ref="oval:com.ubuntu.xenial:tst:2019114770000000"
then in that test, find object: oval:com.ubuntu.xenial:obj:201245420000000, which represent 'linux' package binaries.

# oval:com.ubuntu.xenial:obj:201245420000000

        <linux-def:dpkginfo_object id="oval:com.ubuntu.xenial:obj:201245420000000" version="1" comment="The 'linux' package binaries.">
            <linux-def:name var_ref="oval:com.ubuntu.xenial:var:201245420000000" var_check="at least one" />
        </linux-def:dpkginfo_object>

in this `dpkginfo_object`, <linux-def:name> used to contain only the name of the binary package, but now it contains a var_ref which points to multiple full name of the most recent binary package for linux kernel image:

# oval:com.ubuntu.xenial:var:201245420000000
         <constant_variable id="oval:com.ubuntu.xenial:var:201245420000000" version="1" datatype="string" comment="'linux' package binaries">
            <value>linux-image-4.4.0-151-generic</value>
            <value>linux-image-4.4.0-151-generic-lpae</value>
            <value>linux-image-4.4.0-151-lowlatency</value>
            <value>linux-image-4.4.0-151-powerpc-e500mc</value>
            <value>linux-image-4.4.0-151-powerpc-smp</value>
            <value>linux-image-4.4.0-151-powerpc64-emb</value>
            <value>linux-image-4.4.0-151-powerpc64-smp</value>
            <value>linux-image-unsigned-4.4.0-151-generic</value>
            <value>linux-image-unsigned-4.4.0-151-lowlatency</value>
        </constant_variable>

In previous version, an object of 'Linux' package has no var_ref and looks like this:

# oval:com.ubuntu.xenial:obj:20137445000
        <linux-def:dpkginfo_object id="oval:com.ubuntu.xenial:obj:20137445000" version="1" comment="The 'linux' package.">
            <linux-def:name>linux</linux-def:name>
        </linux-def:dpkginfo_object>

Compare the object above to the recent version
 oval:com.ubuntu.xenial:obj:201245420000000, we can see there's a change of 'linux' package object, but of which meaning is not yet clear.

I believe this is an error, an 'linux' binary package should not contain any version information, as can be seen in other packages objects which only contains a name of package.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1834439

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Hombre (tokamak)]

I think this is not in any situation needed a kernel trace or machine based info-gathering. can you please forward this to someone who produce the OVAL definition in https://people.canonical.com/~ubuntu-security/oval/? they will understand immediately what I'm talking about.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1834439

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Hombre (tokamak)]

this issue is unrelated to the actual linux operating system but the OVAL definition ubuntu security team has provided.
hence the obvious omission of log files.

[Alex Murray (alexmurray)]

Reassigning to the ubuntu-cve-tracker project since this is the relevant project

[Joy Latten (j-latten)]

The current cve oval behavior is correct as currently defined.

"linux" is the name of a source package, not a binary package. Therefore "dpkg -s linux" is not quite correct and that is what happens in the OVAL if you do,

# oval:com.ubuntu.xenial:obj:20137445000
        <linux-def:dpkginfo_object id="oval:com.ubuntu.xenial:obj:20137445000" version="1" comment="The 'linux' package.">
            <linux-def:name>linux</linux-def:name>
        </linux-def:dpkginfo_object>

The above checks that the source package is installed to ensure the system is not vulnerable to the CVE. That is incorrect. It should be checking that the binary packages associated with the source package is installed.

The cve oval was changed such the binary packages associated with a source package are collected into an oval variable for reuse. A particular OVAL check may check that a version >= to version of the binary package fixed by the CVE is installed.

Conclusion: The current cve oval to check for binary packages and a particular version to be installed rather then source packages is correct.

[Hombre (tokamak)]

I understand one is for source package, and another is for binary package derived from source package. and we used to parse that in our implementation.
BUT the confusion stems from that you gave a version number for the binary package ** object **, in this case,

    linux-image-4.4.0-151-generic

this object represents 'linux' package binaries, and is used in OVAL test
    oval:com.ubuntu.xenial:tst:2019114770000000
to test:
    if "Does the 'linux' package exist and is the version less than '4.4.0-151.178'?"

if you only want to represent the 'linux' package, why are you specifying the version for that binary package though?

in the case of CVE-2019-11477 (oval:com.ubuntu.xenial:def:2019114770000000) Actually in xenial all kernel version lower than 4.4.0-151 is affected. and that comparison target is specified in ** state **:

    <linux-def:dpkginfo_state id="oval:com.ubuntu.xenial:ste:2019114770000000" version="1" comment="The package version is less than '4.4.0-151.178'.">
    <linux-def:evr datatype="debian_evr_string" operation="less than">4.4.0-151.178</linux-def:evr>

what is the point of specifying a version in the ** object **?

[Alex Murray (alexmurray)]

The name of the binary package contains the version number itself - this is not something that is being added in the OVAL output, but is the name package itself - see https://packages.ubuntu.com/xenial/linux-image-4.4.0-151-generic as an example - so that is the object.

[Hombre (tokamak)]

I understand that because of breaking ABI change you must rename the binary package whenever newer kernel image is released. but this didn't help at clarifying the question.

according to this page https://packages.ubuntu.com/source/xenial/linux-signed, 'linux' source package builds a lot of binary packages besides linux-image-4.4.0-154-generic (according to newest definition), I think it's not adequate make 4.4.0-154 represent binary package for 'linux'.

imagine a user has linux-image-4.4.0-112-generic(built from 'linux') installed on system, but the existence of 'linux' binary package is not identified because it is not linux-image-4.4.0-154-generic.

[Joy Latten (j-latten)]

The version is required, otherwise how would you know if the version of the kernel installed on system is vulnerable or not? When a CVE is applied to a package, the package is re-built and the version number is incremented according to policy. Thus you will only know if the package installed on the system is vulnerable or not by checking its version.

[Hombre (tokamak)]

IMHO that's not how we do comparison using OVAL definition, take definition of CVE-2019-11477 for example:

        </linux-def:dpkginfo_test>
        <linux-def:dpkginfo_test id="oval:com.ubuntu.xenial:tst:2019114770000000" version="1" check_existence="at_least_one_exists" check="at least one" comment="Does the 'linux' package exist and is the version less than '4.4.0-151.178'?">
            <linux-def:object object_ref="oval:com.ubuntu.xenial:obj:201245420000000"/>
            <linux-def:state state_ref="oval:com.ubuntu.xenial:ste:2019114770000000" />
        </linux-def:dpkginfo_test>

here we test 'linux' package against **state** to find out if the package is vulnerable or not. we are NOT using any version information from **object** itself for our decision. only thing we require from an object is that the target package should be compiled from 'linux' source package. yet in recent OVAL definition you specify a that strange var_ref variable with a list of most recent binary package.

I hope we get crystal clear on this issue. there's clearly something not right here.

[Hombre (tokamak)]

I really hope I have made my point and not being overly stubborn here. To compare an object to a state, our implementation will try to detect the actual version of that object from target system, rather than using a pre-defined version because that would render the comparison meaningless