Date: Tue, 19 Sep 2017 19:16:00 +0200 From: Solar Designer <solar@...nwall.com> To: riel@...hat.com Cc: linux-kernel@...r.kernel.org, danielmicay@...il.com, tytso@....edu, keescook@...omium.org, hpa@...or.com, luto@...capital.net, mingo@...nel.org, x86@...nel.org, linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com, linux-sh@...r.kernel.org, ysato@...rs.sourceforge.jp, kernel-hardening@...ts.openwall.com Subject: Re: [PATCH v2 0/5] stackprotector: ascii armor the stack canary On Wed, May 24, 2017 at 11:57:46AM -0400, riel@...hat.com wrote: > Zero out the first byte of the stack canary value on 64 bit systems, > in order to mitigate unterminated C string overflows. > > The null byte both prevents C string functions from reading the > canary, and from writing it if the canary value were guessed or > obtained through some other means. > > Reducing the entropy by 8 bits is acceptable on 64-bit systems, > which will still have 56 bits of entropy left, but not on 32 > bit systems, so the "ascii armor" canary is only implemented on > 64-bit systems. > > Inspired by the "ascii armor" code in execshield and Daniel Micay's > linux-hardened tree. > > Also see https://github.com/thestinger/linux-hardened/ Brad trolls us all lightly with this trivia question: https://twitter.com/grsecurity/status/905246423591084033 "For #trivia can you describe one scenario where this change actually helps exploitation using similar C string funcs?" I suppose the expected answer is: The change helps exploitation when the overwriting string ends just before the canary. Its NUL overwriting the NUL byte in the canary would go undetected. Before this change, there would be a 255/256 chance of detection. I hope this was considered. The change might still be a good tradeoff, or it might not, depending on which scenarios are more likely (leak of canary value or the string required in an exploit ending at that exact byte location), and we probably lack such statistics. I am not proposing to revert the change. I had actually contemplated speaking up when this was discussed, but did not for lack of a better suggestion. We could put/require a NUL in the middle of the canary, but with the full canary being only 64-bit at most that would also make some attacks easier. So this is JFYI. No action needed on it, I think. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.