linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Denis Efremov <efremov@linux.com>
To: "Weber, Matthew L Collins" <Matthew.Weber@collins.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	LSM List <linux-security-module@vger.kernel.org>,
	keescook@chromium.org
Subject: Re: Linux Kernel vulnerability scripting
Date: Tue, 3 Aug 2021 23:50:12 +0300	[thread overview]
Message-ID: <53ad0be9-5fd6-8805-98dc-0d8889c546db@linux.com> (raw)
In-Reply-To: <CY1P110MB0102E9CF9461FDAA8C3B8C22F2F09@CY1P110MB0102.NAMP110.PROD.OUTLOOK.COM>

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

      reply	other threads:[~2021-08-03 20:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03 20:07 Linux Kernel vulnerability scripting Weber, Matthew L Collins
2021-08-03 20:50 ` Denis Efremov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53ad0be9-5fd6-8805-98dc-0d8889c546db@linux.com \
    --to=efremov@linux.com \
    --cc=Matthew.Weber@collins.com \
    --cc=acme@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).