Re: [PATCH] [RFC] Deter exploit bruteforcing

[Richard Weinberger]

Am 02.01.2015 um 20:46 schrieb Pavel Machek:
>>> Does this break trinity, crashme, and similar programs?
>>
>> If they fork() without execve() and a child dies very fast the next fork()
>> will be throttled.
>> This is why I'd like to make this feature disabled by default.
>>
>>> Can you detect it died due to the stack canary? Then, the patch might
>>> be actually acceptable.
>>
>> I don't think so as this is glibc specific.
> 
> Can the slowdown be impelmented in glibc, then?

glibc has a lot of asserts where it can detect stack smashing and kills the
current process using abort(). Here it could of course also call sleep().

> If not, can glibc provide enough information to the kernel to allow us
> to do the right thing?

IMHO we should not strictly focus on the stack canary.
If an attacker can kind of control the attacked child and it segfaults the generic
in-kernel bruteforce detection will still work.
Many exploits use the fact that after fork() the child has the same memory as before
and brute force is possible. A user space solution won't help here.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/