Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALS6=qXN_UxEYV-6kG9_r6kv5joYdVpKU6xOhxLsPAkshzN80g@mail.gmail.com>
Date: Fri, 22 Feb 2019 00:20:19 +0800
From: Carter Cheng <cartercheng@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: classes of methods for gaining access to kernel memory

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@...omium.org> wrote:

> On Sun, Feb 10, 2019 at 3:13 AM Carter Cheng <cartercheng@...il.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
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.