[kernel-hardening] Stack guard canary massaging

[kernel-hardening] Stack guard canary massaging

[Florian Weimer]

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

[kernel-hardening] Re: Stack guard canary massaging

[Solar Designer]

On Mon, Oct 31, 2016 at 11:48:45AM +0100, Florian Weimer wrote:
> Sorry for cross-posting.

Sorry to bikeshed, but I think this isn't a kernel-hardening topic at
all, so the thread should continue on oss-security only, please.

Florian, if there's a reason why you think it's kernel-hardening
related, please let me know.  To me, it looks like userspace hardening
that is not even kernel-assisted (at least not directly in this place,
even though the kernel may have helped provide the random numbers).

If your cross-posting was to reach more of the right people, then you
have already done so, and they can join oss-security now. ;-)

Alexander

Re: [kernel-hardening] Re: Stack guard canary massaging

[Daniel Micay]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

On Mon, 2016-10-31 at 12:22 +0100, Solar Designer wrote:
> On Mon, Oct 31, 2016 at 11:48:45AM +0100, Florian Weimer wrote:
> > Sorry for cross-posting.
> 
> Sorry to bikeshed, but I think this isn't a kernel-hardening topic at
> all, so the thread should continue on oss-security only, please.
> 
> Florian, if there's a reason why you think it's kernel-hardening
> related, please let me know.  To me, it looks like userspace hardening
> that is not even kernel-assisted (at least not directly in this place,
> even though the kernel may have helped provide the random numbers).
> 
> If your cross-posting was to reach more of the right people, then you
> have already done so, and they can join oss-security now. ;-)
> 
> Alexander

The kernel supports SSP but it doesn't appear to do the same thing.

arch/*/include/asm/stackprotector.h

Why do the non-x86 implementations XOR in LINUX_VERSION_CODE though? Is
it supposed to be a placeholder for a random at compile-time value? :\

It's not harmful but that's just... weird.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [kernel-hardening] Re: Stack guard canary massaging

[Jann Horn]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

[-CC oss-security, this is just about kernel stuff]

On Mon, Oct 31, 2016 at 07:41:04AM -0400, Daniel Micay wrote:
> On Mon, 2016-10-31 at 12:22 +0100, Solar Designer wrote:
> > On Mon, Oct 31, 2016 at 11:48:45AM +0100, Florian Weimer wrote:
> > > Sorry for cross-posting.
> > 
> > Sorry to bikeshed, but I think this isn't a kernel-hardening topic at
> > all, so the thread should continue on oss-security only, please.
> > 
> > Florian, if there's a reason why you think it's kernel-hardening
> > related, please let me know.  To me, it looks like userspace hardening
> > that is not even kernel-assisted (at least not directly in this place,
> > even though the kernel may have helped provide the random numbers).
> > 
> > If your cross-posting was to reach more of the right people, then you
> > have already done so, and they can join oss-security now. ;-)
> > 
> > Alexander
> 
> The kernel supports SSP but it doesn't appear to do the same thing.
> 
> arch/*/include/asm/stackprotector.h
> 
> Why do the non-x86 implementations XOR in LINUX_VERSION_CODE though? Is
> it supposed to be a placeholder for a random at compile-time value? :\

Only for the init task though.
For the others, it's chosen in dup_task_struct() (in kernel/fork.c),
using get_random_int() - which returns a 32-bit number, either straight
from RDRAND or from an MD5-based RNG using percpu state.

As far as I can tell, this means that the init task is the only one
that can have a 64-bit canary (e.g. on amd64); all the others have
canaries where the more significant half is all zeroes. Although
bruteforcing 32 bits isn't exactly easy, this should probably be fixed.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]