Re: magic constants in some startup code

[Richard Gorton <rcgorton@cognitive-electronics.com>]

Thank you (and a follow up question) - what code looks at this canary?  It is assigned to pthread_self()->canary, but I do not see any code inside musl itself that checks that value?  A work in progress?  Or does other code check this value?

Regards,
	Richard

On Oct 31, 2014, at 10:18 AM, Rich Felker <dalias@libc.org> wrote:
> 
>> ----
>> 
>> src/env/__stack_chk_fail.c
>> 	else __stack_chk_guard = (uintptr_t)&__stack_chk_guard * 1103515245;
>> 
>> the number equates to 0x41c64e6d.
>> Called from __init_libc as:
>> 	 __init_ssp((void *)aux[AT_RANDOM]); 
>> The kernel is putting a random number into aux[AT_RANDOM] at process initialization.
>> Why not just put a predictable arbitrary number into __stack_chk_guard?
> 
> The reason you don't want a predictable arbitrary number for the stack
> guard canary is that it makes it easy to bypass stack-protector by
> including the known number in your overflow payload.
> 
> The idea in the above code, which really deserves a comment, is to
> attempt to recover _some_ entropy from the address at which libc is
> mapped (which hopefully was affected by ASLR) when AT_RANDOM is not
> available. Modern Linux kernels always give you AT_RANDOM, so this
> code path would only be taken on an ancient Linux version or a
> non-Linux host.
> 
> The magic number 1103515245 is just a LCG, the same as what's used in
> musl's rand_r() and in the C standard's sample rand(). It serves to
> mix the bits somewhat, accounting for the likelihood that the mapping
> address is not very random in some of its bits.
> 
> None of this is really very effective, but I've left it there because
> it seems "better than nothing".
> 
> Rich