Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 19 Sep 2017 13:22:52 -0700
From: Kees Cook <>
To: Solar Designer <>
Cc: Rik van Riel <>, LKML <>, 
	Daniel Micay <>, "Ted Ts'o" <>, "H. Peter Anvin" <>, 
	Andy Lutomirski <>, Ingo Molnar <>, 
	"" <>, 
	"" <>, 
	Catalin Marinas <>, linux-sh <>, 
	Yoshinori Sato <>, 
	"" <>
Subject: Re: [PATCH v2 0/5] stackprotector: ascii armor the
 stack canary

On Tue, Sep 19, 2017 at 10:16 AM, Solar Designer <> wrote:
> On Wed, May 24, 2017 at 11:57:46AM -0400, 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
> Brad trolls us all lightly with this trivia question:
> "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:
the same kernels had 4 NULL bytes in a row. ;) So it's all an improvement, IMO.


Kees Cook
Pixel Security

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.