On Sat, Jan 3, 2015 at 3:19 PM, Richard Weinberger <richard@xxxxxx> wrote: > Am 04.01.2015 um 00:06 schrieb Andy Lutomirski: >> As an attempt to help end this particular line of debate: putting the >> sleep in glibc won't work. The point isn't to make the crashed >> process crash more slowly; it's to limit the rate at which *new* >> siblings can be forked and crashed as a canary or ASLR brute-force >> probe. IOW, adding a sleep call to glibc slows down the wrong thing. >> Also, trying to get libc to take action on a plain old segfault is a >> giant mess, because it involves mucking with signal handling, which >> glibc really has no business doing by default. > > Thanks for pointing this out! Yeah, this doesn't belong in glibc. The support for fork-speed-control must be in the kernel. Improving glibc is an entirely separate idea. For glibc, it would be nice to create a "halp, I'm being attacked" syscall that like abort(), but used in cases of memory corruption, etc. This would provide a much cleaner way for programs to communicate to the kernel that something malicious is happening. Neither SIGABRT nor SIGSYS are quite right for this, but SIGSYS (as used by seccomp) is likely closer. >> Also, this patch is missing a bit, I think. We really want to control >> the total rate of crashes. This patch imposes a delay per crash, but >> AFAICS it would still be possible for an attacker to coerce a forking >> server to fork, say, 10k children, then probe all of them, then wait >> 30 seconds and repeat. I general, while I would expect this to be limited by the default RLIMIT_NOFILE of 1024, it's still a valid observation, though the scope is smaller. Regardless, it would still be a defensive benefit to slow down forks. Brad, PaXTeam: have you considered limiting open connections from the same IP address or anything like that for defending against this kind "wide prefork" attack? > Sounds reasonable. This is exactly why I've extracted that feature from > grsecurity and posted it here on LKML. > Now we have the chance to make the feature better and can identify weak points. The grsecurity version also handles set[ug]id binaries more aggressively. https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Deter_exploit_bruteforcing Speaking to "default or not", it needs to be off by default in the kernel configs. It's easy to imagine things that will trip on false positives, so we must first get the system in place in the kernel and improve it until we get to the point where we can set it on by default (this may take years, after all the distros are using it, etc etc). Security feature addition requires a fair bit of patience. :) If you can spin up a version with sysctls and Kconfig stuff, I think that'd be the best next step. -Kees -- Kees Cook Chrome OS Security -- 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
