kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
* classes of methods for gaining access to kernel memory
@ 2019-02-10 11:12 Carter Cheng
  2019-02-21  1:17 ` Kees Cook
  0 siblings, 1 reply; 5+ messages in thread
From: Carter Cheng @ 2019-02-10 11:12 UTC (permalink / raw)
  To: kernel-hardening

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

Hi,

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?

Thanks in advance,

[-- Attachment #2: Type: text/html, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: classes of methods for gaining access to kernel memory
  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
  0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2019-02-21  1:17 UTC (permalink / raw)
  To: Carter Cheng; +Cc: Kernel Hardening

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: classes of methods for gaining access to kernel memory
  2019-02-21  1:17 ` Kees Cook
@ 2019-02-21 16:20   ` Carter Cheng
  2019-02-21 17:15     ` Kees Cook
  0 siblings, 1 reply; 5+ messages in thread
From: Carter Cheng @ 2019-02-21 16:20 UTC (permalink / raw)
  To: Kees Cook; +Cc: Kernel Hardening

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: classes of methods for gaining access to kernel memory
  2019-02-21 16:20   ` Carter Cheng
@ 2019-02-21 17:15     ` Kees Cook
  2019-02-21 19:36       ` Carter Cheng
  0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2019-02-21 17:15 UTC (permalink / raw)
  To: Carter Cheng; +Cc: Kernel Hardening

On Thu, Feb 21, 2019 at 8:20 AM Carter Cheng <cartercheng@gmail.com> wrote:
> 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.

Can you share some URLs and/or examples? I'm sure other folks here
would be interested to read those too.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: classes of methods for gaining access to kernel memory
  2019-02-21 17:15     ` Kees Cook
@ 2019-02-21 19:36       ` Carter Cheng
  0 siblings, 0 replies; 5+ messages in thread
From: Carter Cheng @ 2019-02-21 19:36 UTC (permalink / raw)
  To: Kees Cook; +Cc: Kernel Hardening

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

One of the papers I had a brief look at is this one-

https://ieeexplore.ieee.org/abstract/document/7546545



On Fri, Feb 22, 2019 at 1:16 AM Kees Cook <keescook@chromium.org> wrote:

> On Thu, Feb 21, 2019 at 8:20 AM Carter Cheng <cartercheng@gmail.com>
> wrote:
> > 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.
>
> Can you share some URLs and/or examples? I'm sure other folks here
> would be interested to read those too.
>
> --
> Kees Cook
>

[-- Attachment #2: Type: text/html, Size: 1241 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-02-21 19:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-02-21 17:15     ` Kees Cook
2019-02-21 19:36       ` Carter Cheng

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).