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? 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
