> >> 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). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
