Re: A Famous Security Bug

On 25/03/2024 23:31, Michael S wrote:

On Mon, 25 Mar 2024 21:25:27 +0000
bart <bc@freeuk.com> wrote:

Your explanation exactly matches what I was imagining.
The technology for relocation of non-PIC code is already here, in
file format definitions and in OS loader code. The linker or the
part of compiler that serves the role of linker can decide to not
generate required tables. Operation in such mode will have small
benefits in EXE size and in quicker load time, but IMHO nowadays it
should be used rarely, only in special situations rather than serve
as a default of the tool.

>
There are two aspects to be considered:
>
* Relocating a program to a different address below 2GB
>
* Relocating a program to any address including above 2GB
>
The first can be accommodated with tables derived from the reloc info
of object files.
>
But the second requires compiler cooperation in generating code that
will work above 2GB.
>
Part of that can be done with RIP-relative address modes as I touched
on. But not all; RIP-relative won't work here:
>
      movsx rax, dword [i]
      mov rax, [rbx*8 + abc]
>
where the address works with registers. This requires something like:
>
      lea rcx, [rip:abc]         # or mov rcx, abc   (64-bit abs addr)
      mov rax, [rbx*8 + rcx]
>
This is specific to x64, but other processors will have their issues.
Like ARM64 which doesn't even have the 32-bit displayment used with
rip here.
>

 You mean, when compiler knows that the program is loaded at low address
and when combined data segments are relatively small then compiler can
use zero-extended or sign-extended 32-bit literals to form 64-bit
addresses of static/global objects?
I see how relocation of such program is a problem in 64-bit mode, but
still fail to see how similar problem could happen in 32-bit mode.
 

At 32 bits the problems of high-loading disappear, as programs and data need to fit into 2GB.
Some problems with relocating remain. RIP-relative can't be used, as I believe that works only in 64-bit mode.
What remains are the base-relocations, which had in the past only been needed when generating dynamic libraries like DLLs. They just weren't a thing for EXE.
This then reduces to whether the C toolset will generate the right EXE. Either it does or doesn't, but you can always choose a different compiler.
All I can tell you is that of the suite of 5 compilers I've tried, 4 of them, including in 32-bit mode if supported, don't generate an EXE that will be loaded at an arbitrary address. Only gcc will do that.
The same goes for Clang run at rextester.com: that doesn't load high (but it could also be an old version).
Maybe some don't think it's that important. But it's not as straightforward as you seem to think. Yes, it might have been a bit simpler with 32 bits, but it wasn't trendy then, and not not many still use 32 bits.