From: Kees Cook <keescook@chromium.org>
To: Len Baker <len.baker@gmx.com>
Cc: "kernelnewbies@kernelnewbies.org"
<kernelnewbies@kernelnewbies.org>,
linux-hardening@vger.kernel.org
Subject: Re: [Clarification] writes to kernel addresses that came from userspace
Date: Sun, 12 Sep 2021 11:47:10 -0700 [thread overview]
Message-ID: <202109121140.07EF06758@keescook> (raw)
In-Reply-To: <20210912162030.GA4692@titan>
On Sun, Sep 12, 2021 at 06:20:30PM +0200, Len Baker wrote:
> I am taking a look to the issues in the Kernel Self Protection Project [1]
> and this one [2] (perform taint-tracking of writes to kernel addresses
> that came from userspace) take my attention. Reading the explanation does
> not make it clear to me where the flaw is.
>
> [extracted from the KSPP]
>
> It should be possible to perform taint tracking of addresses in the kernel
> to avoid flaws of the form:
>
> copy_from_user(object, src, ...);
> ...
> memcpy(object.address, something, ...);
>
> [end of extracted]
>
> My question is: Why is this scenario a flaw?
I likely didn't give enough context in the Issue tracker. It's not a
flaw on its own, but rather an example of an attack situation if a flaw
were present (e.g. having no sanity-check on "object.address" above).
> If I understand correctly, the copy_from_user() function copies n bytes of
> src (in user space address) to object (in kernel space address). I think
> that it is the correct way to act. Then, in kernel space the object is
> modified. So, I don't see the problem. Sorry if it is a trivial question
> but I can not figure it out on my own.
The trouble is that the address came from userspace and (in this
example) has no validation, etc.
This Issue is about developing methods to perform "taint tracking"
within the kernel to better catch cases where validation is missing.
There is some limited support for this via the "__user" annotation and
the "address spaces" checks that "sparse" does, but that's been rather
limited in scope. Having something more like smatch doing function-graph
analysis would be nice for static analysis, and even better would be
stuff like DataFlowSanitizer[1], which can do this at runtime.
Hopefully that makes things more clear! I'll go update the issue
tracker. :)
-Kees
[1] https://clang.llvm.org/docs/DataFlowSanitizer.html
> [1] https://github.com/KSPP/linux/issues
> [2] https://github.com/KSPP/linux/issues/126
--
Kees Cook
parent reply other threads:[~2021-09-12 18:47 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20210912162030.GA4692@titan>]
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=202109121140.07EF06758@keescook \
--to=keescook@chromium.org \
--cc=kernelnewbies@kernelnewbies.org \
--cc=len.baker@gmx.com \
--cc=linux-hardening@vger.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).