Re: Randomize offset between program segments?

[Topi Miettinen <toiwoton@gmail.com>]

On 29.10.2020 10.04, Siddhesh Poyarekar wrote:
> On 10/21/20 4:14 PM, Topi Miettinen wrote:
>>> The alternative (which is what PIC does for global variables) is to have
>>> a GOT-like indirection, where instead of the single pc-relative load,
>>> the compiler emits a load from that table and a subsequent load from the
>>> address in GOT.  Here, patching by the dynamic linker is safe since the
>>> offset table is rw, but you will have doubled the number of instructions
>>> needed to access your data.
>>
>> Also size of GOT will increase. Otherwise this seems a better approach.
> 
> You shouldn't use GOT (because it's the *global* offset table) but a
> similar idea.  A rose by another name...

A table containing offsets would be used, so why not GOT? What kind of 
globalness the name refers to? One GOT is local to the program but each 
shared library has an own local GOTs.

>> I don't know. What would be the method to quantify such benefits? This
>> applies to a specific case where the attacker is able to determine an
>> address in one segment but needs to find an address in another segment
>> in order to win, and without ASLR the offset between the addresses would
> 
> First build evidence for this possibility, i.e. how easy is it to
> determine the address of one segment in a binary and how much
> *incremental* effort does it take to determine the address of other
> segments?
> 
>> be always known by the attacker (for example, because the distro and the
>> version for the program or library is known). Without ASLR, chance of
>> winning is 100%. With ASLR, this could be related to number of bits in
>> randomization. In the 32 bit offset case this would be 20 bits (assuming
>> 12 bits page size), so the chances of guessing would be 2^-20 and brute
>> forcing the offset would be expected to take 2^20/2 attempts.
> 
> Question is, would it really be an additional 2^20 tries at all times?
> For example, the offset table has to be at a known offset from the code
> and hence could be computed once you know the address of the code
> segment.  From there, the final address for the data access is just an
> indirection away.

Right, and the same also applies if a register would be dedicated to 
access the data areas. The compiler might be able to pick a random 
register, but then it's easy for the attacker to guess it from the very 
few registers. I don't think this approach will be useful after all.

Perhaps randomness could be increased by other means. When compiling, 
each .o file could be compiled into a shared object. Then these small 
pieces of a program or library could be placed independently. This 
probably wouldn't require any changes except for build logic in 
Makefiles etc. Now, could this be achieved without dozens of .so files, 
so that all shared objects would be contained in a single ELF file? But 
this is not relevant to libc anymore.

-Topi