Am 04.01.2015 um 00:01 schrieb Pavel Machek: > On Sat 2015-01-03 23:44:18, Richard Weinberger wrote: >> Am 03.01.2015 um 23:36 schrieb Pavel Machek: >>> >>>>>> 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. >>> >>> Please do. >>> >>>>> 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. >>> >>> Only "interesting" systems that are without glibc are androids, and >>> they usually run very old kernels. >>> >>> If you implement sleep() in glibc, distros will enable it and you'll >>> protect all the desktop users. >>> >>> If you implement it in kernel, it will not be compatible-enough to be >>> enabled by default, and you'll be protecting special "high security" >>> distros at most. >>> >>>> And many applications make system calls without going though any libc wrapper. >>>> Hey, we want also protect esoteric distros like http://sta.li. :-) >>> >>> No, we don't. We want to maximize number of protected users. And >>> patching glibc does that. (And then you can patch bionic. And then the >>> small players will follow). >> >> And what about static linked programs or programs which do not use a libc wrapper >> for system calls? >> Say, any program written in go? > > And what about my Atari 800XL? If it runs Linux it can be protected. > How many such programs are on common distributions? <1% > > How many systems will your kernel hack leave unprotected? >70% > > (Plus, reasonable languages like go should not really allow classical > buffer overflows, and yes, you'll get protection if you statically > link against glibc. And AFAICT this has nothing to do with syscalls, > and everything to do with abort() implementation.). Go does not use libc at all. Anyway, you've stated your point. I'm for a generic solution and not for one which works only for some systems. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
