On Sun, Sep 13, 2020 at 7:55 PM John Wood <john.wood@xxxxxxx> wrote: > On Thu, Sep 10, 2020 at 11:10:38PM +0200, Jann Horn wrote: > > On Thu, Sep 10, 2020 at 10:22 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > To detect a fork brute force attack it is necessary to compute the > > > crashing rate of the application. This calculation is performed in each > > > fatal fail of a task, or in other words, when a core dump is triggered. > > > If this rate shows that the application is crashing quickly, there is a > > > clear signal that an attack is happening. > > > > > > Since the crashing rate is computed in milliseconds per fault, if this > > > rate goes under a certain threshold a warning is triggered. [...] > > > + delta_jiffies = get_jiffies_64() - stats->jiffies; > > > + delta_time = jiffies64_to_msecs(delta_jiffies); > > > + crashing_rate = delta_time / (u64)stats->faults; > > > > Do I see this correctly, is this computing the total runtime of this > > process hierarchy divided by the total number of faults seen in this > > process hierarchy? If so, you may want to reconsider whether that's > > really the behavior you want. For example, if I configure the minimum > > period between crashes to be 30s (as is the default in the sysctl > > patch), and I try to attack a server that has been running without any > > crashes for a month, I'd instantly be able to crash around > > 30*24*60*60/30 = 86400 times before the detection kicks in. That seems > > suboptimal. > > You are right. This is not the behaviour we want. So, for the next > version it would be better to compute the crashing period as the time > between two faults, or the time between the execve call and the first > fault (first fault case). > > However, I am afraid of a premature detection if a child process fails > twice in a short period. > > So, I think it would be a good idea add a new sysctl to setup a > minimum number of faults before the time between faults starts to be > computed. And so, the attack detection only will be triggered if the > application crashes quickly but after a number of crashes. > > What do you think? You could keep a list of the timestamps of the last five crashes or so, and then take action if the last five crashes happened within (5-1)*crash_period_limit time.
