Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Nov 2020 16:09:21 -0800
From: Randy Dunlap <>
To: John Wood <>, Kees Cook <>,
 Jann Horn <>
Cc: Jonathan Corbet <>, James Morris <>,
 "Serge E. Hallyn" <>,,,,
Subject: Re: [PATCH v2 7/8] Documentation: Add documentation for the Brute LSM

On 11/9/20 10:23 AM, John Wood wrote:
> Hi,
> Thanks for the typos corrections. Will be corrected in the next patch
> version.
> On Sun, Nov 08, 2020 at 08:31:13PM -0800, Randy Dunlap wrote:
>> So an app could read crash_period_threshold and just do a new fork every
>> threshold + 1 time units, right? and not be caught?
> Yes, you are right. But we must set a crash_period_threshold that does not
> make an attack feasible. For example, with the default value of 30000 ms,
> an attacker can break the app only once every 30 seconds. So, to guess
> canaries or break ASLR, the attack needs a big amount of time. But it is
> possible.
> So, I think that to avoid this scenario we can add a maximum number of
> faults per fork hierarchy. Then, the mitigation will be triggered if the
> application crash period falls under the period threshold or if the number
> of faults exceed the maximum commented.
> This way, if an attack is of long duration, it will also be detected and
> mitigated.
> What do you think?

That sounds reasonable to me.


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.