kernel-hardening - Stack guard canary massaging

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <14b76703-8185-dadb-7605-10496331452c@redhat.com>
Date: Mon, 31 Oct 2016 11:48:45 +0100
From: Florian Weimer <fweimer@...hat.com>
To: kernel-hardening@...ts.openwall.com, oss-security@...ts.openwall.com
Subject: Stack guard canary massaging

Sorry for cross-posting.

glibc does this to set up the stack canary:

static inline uintptr_t __attribute__ ((always_inline))
_dl_setup_stack_chk_guard (void *dl_random)
{
   union
   {
     uintptr_t num;
     unsigned char bytes[sizeof (uintptr_t)];
   } ret = { 0 };

   if (dl_random == NULL)
     {
       ret.bytes[sizeof (ret) - 1] = 255;
       ret.bytes[sizeof (ret) - 2] = '\n';
     }
   else
     {
       memcpy (ret.bytes, dl_random, sizeof (ret));
#if BYTE_ORDER == LITTLE_ENDIAN
       ret.num &= ~(uintptr_t) 0xff;
#elif BYTE_ORDER == BIG_ENDIAN
       ret.num &= ~((uintptr_t) 0xff << (8 * (sizeof (ret) - 1)));
#else
# error "BYTE_ORDER unknown"
#endif
     }
   return ret.num;
}

This is an elaborate way of setting ret.bytes[0] = '\0'.

The intent (determined from an old commit message) is to make it harder 
to obtain the canary value through a read buffer overflow of a 
NUL-terminated string: The read overflow will stop at the NUL byte and 
not include the random canary value, reducing the risk of inappropriate 
disclosure.

But this reduces entropy of the canary to 24 bits on 32-bit systems, so 
I wonder if this is the right trade-off here.

Thanks,
Florian

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.