Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751587AbdISUWz (ORCPT ); Tue, 19 Sep 2017 16:22:55 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:45996 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbdISUWy (ORCPT ); Tue, 19 Sep 2017 16:22:54 -0400 X-Google-Smtp-Source: AOwi7QADRma+h0gdYJ1cw6Gcjb9BYuvtrB12oSgH/LMPeQ8wZpnrM1N7NiZ8geMhrgk1w5R5M2MutIl0LRbnxxIXWF8= MIME-Version: 1.0 In-Reply-To: <20170919171600.GA31441@openwall.com> References: <20170524155751.424-1-riel@redhat.com> <20170919171600.GA31441@openwall.com> From: Kees Cook Date: Tue, 19 Sep 2017 13:22:52 -0700 X-Google-Sender-Auth: bi6O0-UXfA9Co1iqA53qDKRLCJM Message-ID: Subject: Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary To: Solar Designer Cc: Rik van Riel , LKML , Daniel Micay , "Ted Ts'o" , "H. Peter Anvin" , Andy Lutomirski , Ingo Molnar , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" , Catalin Marinas , linux-sh , Yoshinori Sato , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2205 Lines: 55 On Tue, Sep 19, 2017 at 10:16 AM, Solar Designer wrote: > On Wed, May 24, 2017 at 11:57:46AM -0400, riel@redhat.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. Agreed. And prior to this: https://git.kernel.org/linus/5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 the same kernels had 4 NULL bytes in a row. ;) So it's all an improvement, IMO. -Kees -- Kees Cook Pixel Security