From: Carter Cheng <cartercheng@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: classes of methods for gaining access to kernel memory
Date: Fri, 22 Feb 2019 00:20:19 +0800 [thread overview]
Message-ID: <CALS6=qXN_UxEYV-6kG9_r6kv5joYdVpKU6xOhxLsPAkshzN80g@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jKoHfPHadabqo=7FaOD1O-GRE1-GowfmZSs_oB+snWFaQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
I was looking over some recent papers for Usenix Security and there are a
couple on data oriented programming and I have been wondering if there are
known mitigation techniques for this kind of data corruption attack or
other attacks that don't involve control flow hijacking.
On Thu, Feb 21, 2019 at 9:17 AM Kees Cook <keescook@chromium.org> wrote:
> On Sun, Feb 10, 2019 at 3:13 AM Carter Cheng <cartercheng@gmail.com>
> wrote:
> > I was reading a paper on kernel data attacks and the paper mentions
> methods for gaining control of kernel memory beyond overflow type attacks.
> This would seem to suggest that methods exist for this in certain cases
> beyond what can be caught by spatial safety checks. Are there general
> classes of such methods that one needs to be aware of? And what are they?
>
> If I follow what you're asking, I'd think race conditions would be an
> example of another major class of attacks against the kernel. For
> example, look at the DirtyCOW attack: that was a race condition
> against the kernel's VFS that wouldn't get caught by bounds checking,
> etc, etc.
>
> --
> Kees Cook
>
[-- Attachment #2: Type: text/html, Size: 1511 bytes --]
next prev parent reply other threads:[~2019-02-21 16:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-10 11:12 classes of methods for gaining access to kernel memory Carter Cheng
2019-02-21 1:17 ` Kees Cook
2019-02-21 16:20 ` Carter Cheng [this message]
2019-02-21 17:15 ` Kees Cook
2019-02-21 19:36 ` Carter Cheng
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='CALS6=qXN_UxEYV-6kG9_r6kv5joYdVpKU6xOhxLsPAkshzN80g@mail.gmail.com' \
--to=cartercheng@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
/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).