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

[Jann Horn <jann@thejh.net>]

[-- 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 --]