Linux Kernel vulnerability scripting

Denis Efremov efremov at linux.com
Tue Aug 3 20:50:12 UTC 2021


Hi,

On 8/3/21 11:07 PM, Weber, Matthew L Collins wrote:
> Hello,
> 
> (I didn't want to spam the whole LKML, so I've included the LSM list and top hits with get_maintainer.pl on the scripts and tools folders.)
> 
> I'm organizing a project to take some prototype scripting and publicly publish/rewrite.  The script I'd like to add to the kernel code base breaks down a kernel build and identifies the active code (using enabled Kconfig and obj file list). 

If I understand you correctly this is what I started to do since the beginning of the year with CVEHound project.
https://github.com/evdenis/cvehound/

Kconfig analysis available with --config option.

> It then uses the kernel version and queries a public vulnerability database(NIST NVD) to identify possible patches against known vulnerabilities.

I take info about fixed CVEs from MITRE, NIST NVD and other sources (RedHat, Ubuntu, linuxkernelcves, ...).
Vulnerable version info in the databases is not reliable. Most of the time I need to figure out the bug commit
and event double check the "Fixes:" tag.

> The script then attempts to patch the source code to determine which vulnerabilities are still present in the codebase.

Just application of a patch with -R option will not work in case the code is modified since the fix and in case of backports.
I describe CVEs with coccinelle patterns. https://coccinelle.gitlabpages.inria.fr/website/
Coccinelle is already broadly used in kernel (see scripts/coccinelle).

> The end goal is to help the user understand the state of the active codebase, whereas most tools stop at the kernel version, and then the activity is all manual.

Exactly. CodeBase+KernelConfig.
Many vendors (e.g. samsung) don't update kernel version info, they just backport fixes.

> For an example of what the scripting impact could improve, a recent Kernel 4.14.x dump of vulnerabilities had hundreds that needed to be paired down.

> Our estimate before tooling put the effort at about 10-15mins a CVE (determine active code, review code paths in suggested patches).

As for now, I described > 200 kernel CVEs with coccinelle patterns.
Usually it takes me exactly 10-15 minutes to write a pattern (without testing it).
I test a pattern to detect a missing fix since the commit the bug was introduced.
https://github.com/evdenis/cvehound/blob/master/tests/test_05_between_fixes_fix.py

I don't rely on kernel version at all. Usually a pattern contains information about
bug conditions or/and about missing fix.

I already found some trophies with it like missing backports:
  https://lkml.org/lkml/2021/1/21/1278
or partial backports:
  https://github.com/oracle/linux-uek/commit/ee7ab9e8f9cb844c4fac8ca9bcc1a0f3f8fdc9bb
  vs
  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/block/rbd.c?h=linux-4.4.y&id=e349a5786f4c23eb11d1e7385703ddbf94f3f061

Regards,
Denis



More information about the Linux-security-module-archive mailing list