Re: [PATCH] [RFC] Deter exploit bruteforcing

[Richard Weinberger]

Am 03.01.2015 um 00:08 schrieb Pavel Machek:
> On Sat 2015-01-03 00:00:22, Richard Weinberger wrote:
>> Am 02.01.2015 um 23:54 schrieb Pavel Machek:
>>> On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
>>>> On Fri, 2 Jan 2015, Pavel Machek wrote:
>>>>
>>>>>> You also want to protect against binaries that are evil on purpose,
>>>>>> right?
>>>>>
>>>>> Umm. No. Not by default. We don't want to break crashme or trinity by
>>>>> default.
>>>>
>>>> I thought trinity is issuing syscalls directly (would make more sense than 
>>>> going through glibc, wouldn't it?) ... haven't checked the source though.
>>>
>>> Patch in this thread wanted to insert delays into kernel on SIGSEGV
>>> processing. That's bad idea by default.
>>
>> No. This is not what this patch does.
>>
>>> But changing glibc to do sleep(30); abort(); instead of abort(); to
>>> slow down bruteforcing of canaries makes some kind of sense... and
>>> should be ok by default.
>>
>> As I saidn only focusing one the specific stack canary case is not enough.
> 
> Ok, so I am now saying "adding random delays to the kernel, hoping
> they slow attacker down" is bad idea. Feel free to add my NAK to the
> patch.

The patch does not add random delays nor is hope involved.

It has a very clear purpose, it makes brute force attacks to forking
services unattractive.
Exploits often use the fact that after fork() the child has the same memory
as the parent and therefore an attacker can start fruitful brute force attacks
to brute stack canaries, offsets, etc. as the new child will always have mostly
the same memory layout as before.

But I'll happily add your NAK to this series.

> If really neccessary, "kill_me_slowly()" syscall would be acceptable,
> but it seems just sleep(); abort(); combination is enough.

The goal of the patch is not to protect only against brute forcing the stack canary.
It should protect against all kind of brute forcing using forking services.

> glibc should cover 99% cases where this matters, please just fix glibc,
> others will follow.

There are a lot of systems out there without glibc.
And many applications make system calls without going though any libc wrapper.
Hey, we want also protect esoteric distros like http://sta.li. :-)

I'm all for implementing as much in user space as possible but in this case the kernel
is the only sane way to offer the protection to _all_ kind of applications.

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/