How Debian OVAL content is structured

Hello everyone! As we saw in the last episode, the results of vulnerability detection for one host produced by two different APIs can vary greatly. Therefore, in order to find out the truth, it is necessary to understand what vulnerability data is provided by the Linux distribution vendor and how this data is structured.

Alternative video link (for Russia): https://vk.com/video-149273431_456239114

Why is it important to do this? Because using data from a Linux distribution vendor, we can ask vulnerability detection API vendors questions: why are you detecting in a different way than described in this data? And then we will understand what caused the difference. And we will either adjust the API for vulnerability detection, or we will adjust the content of the Linux distribution vendor. Either way, it will be a success! In any case, the transparency of the vulnerability detection process will increase.

Last time we looked at vulnerabilities for Debian host and Debian Docker base image. So let’s continue with Debian. In particular, with the official Debian OVAL (Open Vulnerability and Assessment Language) content.

Debian OVAL content can be downloaded from the https://debian.org/security/oval/ website. For Debian 11.6 it will be https://debian.org/security/oval/oval-definitions-bullseye.xml (~48M).

Definitions

I took the very first definition as an example:

As we can see here, Debian OVAL content is organized by CVE IDs and software packages. This is not typical. Typically, OVAL providers organize it by Bulletin IDs. Here we don’t see any Bulletin IDs (DSA or DLA) at all (Upd. Nope, my fault, there are DSAs for some definitions!). The DSA Security Bulletin can be found in crossreferences page. The DLA Security Bulletin can be found in debian-lts-announce (but it’s much more complicated). However, it would be much better if Bulletin IDs were just in the OVAL content in reference tags. It seems right to ask the Debian security team about this.

Upd. 11.01.2023 Actually I was wrong, there are DSAs for some definitions (1935 DSA IDs) !

The detection logic is quite simple. In fact, in each defenition, there is a:

• Debian release test
• Architecture test
• Package version test (for one package only)

Let’s take a closer look at these tests.

oval:org.debian.oval:tst:1 Debian 11 is installed

This test checks that the major version in /etc/debian_version is 11:

vmuser@debian1:~$ cat /etc/debian_version 
11.4

textfilecontent54_test is a test for a text file:

    <textfilecontent54_test id="oval:org.debian.oval:tst:1" version="1" check="all" check_existence="at_least_one_exists" comment="Debian GNU/Linux 11 is installed" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent">
      <object object_ref="oval:org.debian.oval:obj:1"/>
      <state state_ref="oval:org.debian.oval:ste:1"/>
    </textfilecontent54_test>

textfilecontent54_object contains the path to the file and a regular expression to search for:

<textfilecontent54_object id="oval:org.debian.oval:obj:1" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent">
  <path>/etc</path>
  <filename>debian_version</filename>
  <pattern operation="pattern match">(\d+)\.\d</pattern>
  <instance datatype="int">1</instance>
</textfilecontent54_object>

textfilecontent54_state contains the number 11:

    <textfilecontent54_state id="oval:org.debian.oval:ste:1" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent">
      <subexpression operation="equals">11</subexpression>
    </textfilecontent54_state>

In fact, this is an unnecessary check, since oval-definitions-bullseye.xml only contains checks for Debian 11. All definitions in this file use the same distribution version test, checking the same state.

$ cat oval-definitions-bullseye.xml | grep "textfilecontent54_state"
    <textfilecontent54_state id="oval:org.debian.oval:ste:1" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent">
    </textfilecontent54_state>

oval:org.debian.oval:tst:2 all architecture

uname_test should check the architecture of the processor using the uname data.
But in this particular test, there is uname_object but no uname_state.

<uname_test id="oval:org.debian.oval:tst:2" version="1" check="all" check_existence="at_least_one_exists" comment="Installed architecture is all" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix">
      <object object_ref="oval:org.debian.oval:obj:2"/>
    </uname_test>

So, in fact, the architecture is not checked:

<uname_object id="oval:org.debian.oval:obj:2" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix"/>

This is true for all definitions:

cat oval-definitions-bullseye.xml | grep "uname_test"
    <uname_test id="oval:org.debian.oval:tst:2" version="1" check="all" check_existence="at_least_one_exists" comment="Installed architecture is all" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix">
    </uname_test>

It is important. According to the official Debian OVAL content, architecture DOES NOT affect vulnerability detection. Whether this is a bug in the OVAL content or is this the correct logic we will need to understand further. But it makes sense to address the question to the Debian Security Team.

oval:org.debian.oval:tst:3 glibc DPKG is earlier than 2.2-1

Finally, let’s look at dpkginfo_test for detecting a vulnerable version:

    <dpkginfo_test id="oval:org.debian.oval:tst:3" version="1" check="all" check_existence="at_least_one_exists" comment="glibc is earlier than 2.2-1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux">
      <object object_ref="oval:org.debian.oval:obj:3"/>
      <state state_ref="oval:org.debian.oval:ste:2"/>
    </dpkginfo_test>

dpkginfo_object contains the package name:

<dpkginfo_object id="oval:org.debian.oval:obj:3" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux">
  <name>glibc</name>
</dpkginfo_object>

dpkginfo_state contains the patched version:

    <dpkginfo_state id="oval:org.debian.oval:ste:2" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux">
      <evr datatype="debian_evr_string" operation="less than">0:2.2-1</evr>
    </dpkginfo_state>

The version is the same as in the output of dpkg –list (well, you need to add the zero epoch as well):

$ dpkg --list … ii base-files 11.1+deb11u4 amd64 Debian base system miscellaneous files ii base-passwd 3.5.51 amd64 Debian base system master password and group files ii bash 5.1-2+deb11u1 amd64 GNU Bourne Again SHell ii bash-completion 1:2.11-2 all programmable completion for the bash shell ii bind9-dnsutils 1:9.16.27-1~deb11u1 amd64 Clients provided with BIND 9

In conclusion

As you can see, the information related to vulnerability detection (in this OVAL content) can be simplified to a combination of CVE_Number (CVE ID), Distribution_Version, Package_Name and Package_Version:

CVE_Number|Distribution_Version|Package_Name|Package_Version
CVE-1999-0199|Debian 11|glibc|0:2.2-1

Upd. 11.01.2023 There are DSAs for some definitions, so it’s better to use combination of Bulletin, CVE_Number (CVE ID), Distribution_Version, Package_Name and Package_Version

And in the future it is possible to try to write a converter from OVAL to this simplified format and try to detect vulnerabilities with it.

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.