Linux Kernel vulnerability scripting

Linux Kernel vulnerability scripting

[Weber, Matthew L Collins]

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).  It then uses the kernel version and queries a public vulnerability database(NIST NVD) to identify possible patches against known vulnerabilities.  The script then attempts to patch the source code to determine which vulnerabilities are still present in the codebase.  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.  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).  

Is this something that fits within your understanding of the "scripts or tools" included in the kernel codebase?  If so, do scripting-related patches primarily hit the LKML or via subsystem lists related to the topic (I.e., then staging branches via the subsystem for merge).

Thank you for any suggestions of which mailing lists, subsystems, or maintainers I should include on the topic. 

--
Matthew Weber | Associate Director Software Engineer | Commercial Avionics   (Focused in Open Source products and Cybersecurity)
COLLINS AEROSPACE
400 Collins Road NE, Cedar Rapids, Iowa 52498, USA
Tel: +1 319 295 7349 | FAX: +1 319 263 6099
matthew.weber@collins.com 

Re: Linux Kernel vulnerability scripting

[Denis Efremov]

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