Changing stack protector initialization

Changing stack protector initialization

[Florian Weimer]

I need a few more pseudo-random bits (32 instead of 16 on 64-bit 
architectures).  I talked to some cryptography people and they told me 
to expand the 16-byte secret by hashing it with SHA-256.

This key expansion has to happen both in ld.so (for the stack protector 
and pointer guard) and libc.so (for the new stuff).  My first attempt 
failed because doing the initialization in ld.so triggers duplication of 
the new guard variables from libc.so in ld.so, and the libc.so variables 
are never initialized.  (This is very confusing to GDB, which does not 
tell you that you have two variables with the same name at different 
addresses.)

I think the best approach is to duplicate the initialization code and 
run it twice, once based on the _dl_random value, and once using 
getauxval (AT_RANDOM).  The other alternative would be to put the values 
computed by rtld into rtld_global or some similar place and use those 
values to initialize the libc.so variables, but this wastes 16 bytes in 
the data segment per process.  (I need to make a copy so that the 
variable access does not go through the GOT.)

Is there another option to implement this?

Thanks,
Florian

Re: Changing stack protector initialization

[Carlos O'Donell]

On 10/27/2016 10:00 AM, Florian Weimer wrote:
> I need a few more pseudo-random bits (32 instead of 16 on 64-bit
> architectures).  I talked to some cryptography people and they told
> me to expand the 16-byte secret by hashing it with SHA-256.
> 
> This key expansion has to happen both in ld.so (for the stack
> protector and pointer guard) and libc.so (for the new stuff).  My
> first attempt failed because doing the initialization in ld.so
> triggers duplication of the new guard variables from libc.so in
> ld.so, and the libc.so variables are never initialized.  (This is
> very confusing to GDB, which does not tell you that you have two
> variables with the same name at different addresses.)

Could you explain this in a bit more detail?

> I think the best approach is to duplicate the initialization code and
> run it twice, once based on the _dl_random value, and once using
> getauxval (AT_RANDOM).  The other alternative would be to put the
> values computed by rtld into rtld_global or some similar place and
> use those values to initialize the libc.so variables, but this wastes
> 16 bytes in the data segment per process.  (I need to make a copy so
> that the variable access does not go through the GOT.)

I don't like the idea of multiple initialization, it leads to difficult
to answer ordering questions. It is much easier conceptually to initialize
once and then copy the result.
 
> Is there another option to implement this?

Yes, initialize once, and copy the result as required?

-- 
Cheers,
Carlos.

Re: Changing stack protector initialization

[Florian Weimer]

On 10/27/2016 07:03 PM, Carlos O'Donell wrote:
> On 10/27/2016 10:00 AM, Florian Weimer wrote:
>> I need a few more pseudo-random bits (32 instead of 16 on 64-bit
>> architectures).  I talked to some cryptography people and they told
>> me to expand the 16-byte secret by hashing it with SHA-256.
>>
>> This key expansion has to happen both in ld.so (for the stack
>> protector and pointer guard) and libc.so (for the new stuff).  My
>> first attempt failed because doing the initialization in ld.so
>> triggers duplication of the new guard variables from libc.so in
>> ld.so, and the libc.so variables are never initialized.  (This is
>> very confusing to GDB, which does not tell you that you have two
>> variables with the same name at different addresses.)
>
> Could you explain this in a bit more detail?

It's a bit complicated.  I've put the patch on the branch fw/heap-protector.

The branch should build just fine, and the malloc/tst-mallocstate test 
passes.  However, it should fail.

If you set a breakpoint in the middle of do_test, after the 
initialization (say, tst-mallocstate.c:486), you have this situation:

(gdb) print __malloc_header_guard
$2 = 1248978169008729616
(gdb) print &__malloc_header_guard
$5 = (size_t *) 0x555555779128 <__malloc_header_guard>

But look at the disassembly of malloc_usable_size.  It contains:

    0x00007ffff7cd5355 <+37>:    xor    0x322114(%rip),%rax        # 
0x7ffff7ff7470 <__malloc_header_guard>

And of course:

(gdb) print *(size_t *)0x7ffff7ff7470
$6 = 0

Notice the difference address of the variable:

(gdb) info symb 0x7ffff7ff7470
__malloc_header_guard in section .bss of ./libc.so.6
(gdb) info symb 0x555555779128
__malloc_header_guard in section .bss of 
/home/fweimer/src/gnu/glibc/build/elf/ld-linux-x86-64.so.2

I hope this allows you to reproduce the issue easily.

I'll try to propagate the cookie values through GLRO variables.  I do 
not want to access GLRO directly in the malloc code due to performance 
concerns.

Thanks,
Florian