[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Apr 2017 09:54:26 -0700
From: Laura Abbott <labbott@...hat.com>
To: Kees Cook <keescook@...omium.org>, kernel-hardening@...ts.openwall.com
Cc: Michael Leibowitz <michael.leibowitz@...el.com>
Subject: Re: [PATCH 00/18] Introduce struct layout
randomization plugin
On 04/06/2017 02:18 PM, Kees Cook wrote:
> This series brings grsecurity's structure layout randomization plugin
> to upstream. The plugin randomizes the layout of selected structures at
> compile time, as a probabilistic defense against attacks that need to
> know the layout of structures within the kernel. While less useful for
> distribution kernels (where the randomization seed must be exposed for
> third party kernel module builds), it still has some value there since
> now all kernel builds would need to be tracked by an attacker. It is
> most useful to "in-house" kernel builds where the randomization seed
> is not available to an attacker.
>
> One requirement of the plugin is that randomized structures must use
> designated initializers. Many of these have been landing already as
> I've been sending them over the past couple months, but there are
> still some stragglers, which are included here.
>
> Another area to address are places where randomized structures are
> cast to other structures, since there may be implicit positional
> details that need to be addressed. Luckily, there are only a few
> of these false positives, and they have been worked around either
> by adjusting the source or whitelisting them in the plugin.
>
> The plugin selects structures in two ways: manually marked with the
> new __randomize_layout annotation, or automatically when a structure
> is found to consist entirely of function pointers (which can be opted
> out of with the new __no_randomize_layout annotation).
>
> A structure that is especially sensitive and regularly abused in
> exploits is task_struct, but randomizing it requires some special
> handling due to some fields needing to be at the start and end. To
> deal with this, an internal anonymous struct is used to mark the
> portion that will be randomized. I'd love feedback on whether I
> should bite the bullet and perform indenting or violate indenting
> rules to avoid a massive white-space change.
>
> As mentioned, the bulk of this feature is ported over from grsecurity.
> The implementation is almost entirely identical to the original code
> written by Brad Spengler and the PaX Team and Brad Spengler. The
> changes are addition of improved designated initializer markings,
> a whitelisting mechanism, and a different approach to handling the
> task_struct randomization.
>
> I've been doing boot tests with instrumentation showing successfully
> changing offsets within the task_struct, which ran overnight without
> problems. So far, the 0day builder hasn't alerted on anything, but
> it's probably still a bit early.
>
> This series is based on next-20170404.
>
> Patches are:
>
> [PATCH 01/18] gcc-plugins: Add the randstruct plugin
> The plugin itself, with struct auto-detection disabled.
>
> [PATCH 02/18] compiler: Add __designated_init annotation
> [PATCH 03/18] randstruct: Set designated_init attribute
> Adds marking of structures needing designated initialization.
>
> [PATCH 04/18] randstruct: Differentiate bad cast warnings
> Minor clarifications to bad cast warning output.
>
> [PATCH 05/18] af_unix: Use designated initializers
> Designated initializer fix for af_unix (taken for -next already)
> https://lkml.org/lkml/2017/4/6/846
>
> [PATCH 06/18] NFS: Avoid cross-structure casting
> Avoids a false positive in casting (waiting for feedback)
> https://lkml.org/lkml/2017/4/5/530
>
> [PATCH 07/18] randstruct: Whitelist struct security_hook_heads cast
> [PATCH 08/18] randstruct: Whitelist UNIXCB cast
> Whitelist two more false positive cases where source-level
> fixes aren't obvious/possible.
>
> [PATCH 09/18] randstruct: Mark various structs for randomization
> Adds the manual annotation for structures to randomize.
>
> [PATCH 10/18] scsi/bfa: use designated initializers
> [PATCH 11/18] scsi: qedi,qedf: Use designated initializers
> [PATCH 12/18] ovl: Use designated initializers
> The remaining designated initializer fixes for automatic
> struct randomization.
>
> [PATCH 13/18] randstruct: opt-out externally exposed function pointer
> Opt out of some externally-exposed structs that would be
> otherwise automatically randomized.
>
> [PATCH 14/18] randstruct: Disable randomization of ACPICA structs
> Temporary disabling of automatic randomization of ACPICA struct.
>
> [PATCH 15/18] randstruct: Enable function pointer struct detection
> Enables automatic struct randomization.
>
> [PATCH 16/18] task_struct: Allow randomized layout
> Adds selected portion of task_struct to be randomized.
>
> [PATCH 17/18] sgi-xp: Use designated initializers
> Enable randomization of sgi-xp struct, pending feedback.
> https://lkml.org/lkml/2017/3/29/808
>
> [PATCH 18/18] ACPICA: Use designated initializers
> Enable randomization of ACPICA struct, pending feedback.
> https://github.com/acpica/acpica/pull/248/
>
> Testing/feedback appreciated!
>
> -Kees
>
A few more reports from the Fedora config
ipc/sem.c: In function ‘newary’:
ipc/sem.c:507:16: note: found mismatched ssa struct pointer types:
‘struct sem’ and ‘struct sem_array’
sma->sem_base = (struct sem *) &sma[1];
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
This looks like a false positive
security/keys/big_key.c:126:15: note: found mismatched rhs struct
pointer types: ‘struct path’ and ‘void *’
struct path *path = (struct path *)&prep->payload.data[big_key_path];
^~~~
security/keys/big_key.c: In function ‘big_key_free_preparse’:
security/keys/big_key.c:225:16: note: found mismatched rhs struct
pointer types: ‘struct path’ and ‘void *’
struct path *path = (struct path *)&prep->payload.data[big_key_path];
^~~~
security/keys/big_key.c: In function ‘big_key_destroy’:
security/keys/big_key.c:255:16: note: found mismatched rhs struct
pointer types: ‘struct path’ and ‘void *’
struct path *path = (struct path *)&key->payload.data[big_key_path];
^~~~
security/keys/big_key.c: In function ‘big_key_revoke’:
security/keys/big_key.c:238:15: note: found mismatched rhs struct
pointer types: ‘struct path’ and ‘void *’
struct path *path = (struct path *)&key->payload.data[big_key_path];
^~~~
security/keys/big_key.c: In function ‘big_key_read’:
security/keys/big_key.c:293:16: note: found mismatched rhs struct
pointer types: ‘struct path’ and ‘void *’
struct path *path = (struct path *)&key->payload.data[big_key_path];
I'm not quite sure what's going on here, I think it might be
another false positive?
fs/ocfs2/export.c: In function ‘ocfs2_get_dentry’:
fs/ocfs2/export.c:122:10: note: found mismatched ssa struct pointer
types: ‘struct dentry’ and ‘struct inode’
result = (void *)inode;
~~~~~~~^~~~~~~~~~~~~~~
This looks similar to the NFS issue
drivers/net/ethernet/sun/niu.c: In function ‘niu_rx_pkt_ignore’:
drivers/net/ethernet/sun/niu.c:3402:10: note: found mismatched ssa
struct pointer types: ‘struct page’ and ‘struct address_space’
*link = (struct page *) page->mapping;
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/sun/niu.c: In function ‘niu_process_rx_pkt’:
drivers/net/ethernet/sun/niu.c:3472:10: note: found mismatched ssa
struct pointer types: ‘struct page’ and ‘struct address_space’
*link = (struct page *) page->mapping;
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This driver appears to be doing something unique with storing
a page in page->mapping?
The AMD GPU driver has a bunch of warnings about needing to use
explicit initializers.
Thanks,
Laura
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.
