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):

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:

CVE-1999-0199 glibc

Debian GNU/Linux 11
glibc

manual/search.texi in the GNU C Library (aka glibc) before 2.2 lacks a statement about the unspecified tdelete return value upon deletion of a tree’s root, which might allow attackers to access a dangling pointer in an application whose developer was unaware of a documentation update from 1999.

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. 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.

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_object** contains the path to the file and a regular expression to search for:

/etc
debian_version
(d+).d
1

**textfilecontent54_state** contains the number 11:

11

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”

## 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**.

So, in fact, the architecture is not checked:

This is true for **all definitions**:

cat oval-definitions-bullseye.xml | grep “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_object** contains the package name:

glibc

**dpkginfo_state** contains the patched version:

0:2.2-1

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

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.Read More