[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5jJKSLifUfcC1OxEjb-atvPTM14r_6=35gHgZoWVYoScGA@mail.gmail.com>
Date: Fri, 7 Oct 2016 10:07:50 -0700
From: Kees Cook <keescook@...omium.org>
To: "Leibowitz, Michael" <michael.leibowitz@...el.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Brad Spengler <spender@...ecurity.net>, Emese Revfy <re.emese@...il.com>,
PaX Team <pageexec@...email.hu>
Subject: Re: [RFC 0/3] Add struct randomization plugin
On Fri, Oct 7, 2016 at 9:39 AM, Leibowitz, Michael
<michael.leibowitz@...el.com> wrote:
> On Fri, Oct 7, 2016 at 8:40 AM, David Sterba <dave@...os.cz> wrote:
>> Hi,
>>
>> On Thu, May 05, 2016 at 10:21:06AM -0700, Michael Leibowitz wrote:
>>> This patch set ports over grsecurity's structure randomization
>>> feature. The plugin is largely unchanged from grsecurity, with some
>>> porting to go over Emese Revfy's v7 patch set for gcc plugin
>>> infrastructure. This is an RFC.
>>>
>>> Although this set of changes does not directly make exploitation
>>> harder, when a number of structures are randomized, it will make it
>>> difficult to splat many relevant structures without knowing the exact
>>> build of the kernel the target is using. While for one structure,
>>> there are limited number of guesses required, in aggregate, this can
>>> be a large obstacle for exploitation.
>>>
>>> Patch 3 is a grab bag that probably needs to be broken up, although
>>> I'm not sure of the best way to do so. Breaking by subsystem would
>>> seem to make an unwieldy patch set.
>>>
>>> Known TODO that is not addressed as part of this patch set:
>>> * tag security relevant structures for randomization
>>> * add checkpatch checking for non-C99 initialization
>>> * automated testing of randomization
>>> * better description and examples of exploits effectively mitigated
>>> by this feature
>>>
>>> Tagging of structures to be randomized will come in subsequent series
>>> of patches.
>>
>> may I ask what's the status of this patchset? As 4.8 now contains the
>> plugin infrastructure, which I really like to see happening, we could
>> add the remaining plugins. I'm specifically interested in the struct
>> layout randomization.
>
> I'm afraid to say that it got stalled as life moved on. I saw the 4.8
> merge and I have renewed ambition.
>
>> In your initial RFC, the patch 3/3 touches a lot of subsystems, which
>> means potentially dealing with many maintainers. As the patch is a
>> prerequsite for unmodified randstrcut plugin, I think this would stall
>> the inclusion for a long time.
>>
>> The plugin detects "structs with function pointers only" and
>> automatically adds the randomization. I suggest to start without this
>> particular feature, and avoid dependency on patch 3/3.
>>
>> Only the explicit randomize_layout attributes would actually do
>> something. That way the patches could be submitted separately, with it's
>> own reasoning. See the grsecruity patch for examples.
>
> This is an excellent idea. I'm trying that out right now.
Another approach would be to retain the feature, but make it a
separate patch from the main plugin patch. In other words, have the
series as:
- plugin itself (minus all-function-pointers)
- opt-in markings
- C99 changes
- out-out markings
- all-function-pointers plugin logic
>
>> This is not perfect compared to the full featured plugin but I think the
>> proposed way is better than waiting until all issues from patch 3/3 are
>> fixed.
>>
>> I'm willing to help and push things forward, but as you've submitted the
>> patches I'm asking first.
>
> Thanks for the push. I'll give it another try and see if I can a
> patch set out. If I get diverted, though, I'll give you a holler.
Excellent. If you get stalled out, I nominate David to continue the push. :)
Thanks!
-Kees
--
Kees Cook
Nexus Security
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.
