Re: A Famous Security Bug

On 25/03/2024 19:10, bart wrote:

On 25/03/2024 16:51, Michael S wrote:

On Mon, 25 Mar 2024 16:06:24 +0000
bart <bc@freeuk.com> wrote:
>

On 25/03/2024 12:26, David Brown wrote:

On 25/03/2024 12:16, Michael S wrote:

On Sun, 24 Mar 2024 23:43:32 +0100
David Brown <david.brown@hesbynett.no> wrote:

>
I could be  wrong here, of course.

>
It seems, you are.

>
It happens - and it was not unexpected here, as I said.  I don't
have all these compilers installed to test.
>
But it would be helpful if you had a /little/ more information.  If
you don't know why some compilers generate binaries that have
memory mapped at 0x400000, and others do not, fair enough.  I am
curious, but it's not at all important.

>
In the PE EXE format, the default image load base is specified in a
special header in the file:
>
    Magic:            20B
    Link version:     1.0
    Code size:        512 200
    Idata size:       1024 400
    Zdata size:       512
    Entry point:      4096 1000 in data:0
    Code base:        4096
    Image base:       4194304 400000
    Section align:    4096
>
By convention it is at 0x40'0000 (I've no idea why).
>
More recently, dynamic loading, regardless of what it says in the PE
header, has become popular with linkers. So, while there is still a
fixed value in the Image Base file, which might be 0x140000000, it
gets loaded at some random address, usually in high memory above 2GB.
>
I don't know what's responsible for that, but presumably the OS must
be in on the act.
>
To make this possible, both for loading above 2GB, and for loading at
an address not known by the linker, the code inside the EXE must be
position-independent, and have relocation info for any absolute
64-bit static addresses. 32-bit static addresses won't work.
>

>
I don't understand why you say that EXE must be position-independent.
I never learned PE format in depth (and learned only absolute minimum of
elf, just enough to be able to load images in simple embedded
scenario), but my impression always was that PE EXE contains plenty of
relocation info for a loader, so it (loader) can modify (I think
professional argot uses the word 'fix') non-PIC at load time to run at
any chosen position.
Am I wrong about it?

  A PE EXE designed to run only at the image base given won't be position-independent, so it can't be moved anywwhere else.
 There isn't enough info to make it possible, especially before position-independent addressing modes for x64 came along (that is, using offset to the RIP intruction pointer instead of 32-bit absolute addresses).
 Take this C program:
     int abc;
    int* ptr = &abc;
     int main(void) {
        int x;
        x = abc;
    }
 Some of the assembly generated is this:
     abc:   resb 4
     ptr:   dq abc
    ...
           mov eax, [abc]
 That last reference is an absolute 32-bit address, for example it might have address 0x00403000 when loaded at 0x400000.
 If the program is instead loaded at 0x78230000, there is no reloc info to tell it that that particular 32-bit value, plus the 64-bit field initialising ptr, must be adjusted.
 RIP-relative addressing (I think sometimes called PIC), can fix that second reference:
            mov eax, [rip:abc]
 But it only works for code, not data; that initialisation is still absolute.
 When a DLL is generated instead, those will need to be moved (to avoid multiple DLLs all based at the same address). In that case, base-relocation tables are needed: a list of addresses that contain a field that needs relocating, and what type and size of reloc is needed.
 The same info is needed for EXE if it contains flags saying that the EXE could be loaded at an arbitrary adddress.
 

I have a few comments about this.  One is that PIC is "Position Independent Code", while PID is "Position Independent Data".  Enabling PIC on a compiler may imply PID as well, or they may be independent. This can all cause significant run-time costs as access to non-local data and functions has at least one extra layer of indirection - though doing it via a register like RIP reduces that overhead quite a bit.
An alternative method is to have the linker generate a file that contains the executable before the final linking, and a link relocation table.  This is similar to a linkable object file - a reference to the address of the variable "abc" would be replaced by 0x00000000 in the machine code, and an entry in the relocation table would say "fill in the address of abc at position Y from the start of the code section".
Then the program is loaded into memory by a link-loader that fills these blank fields, just the same way as a static linker does when generating the image.  This complicates the loading mechanism and makes it slower to start code, but it runs faster.
There are other ways to do things, possibly combinations of these.
I believe the COFF format, which is the base for Windows executable formats, supports such relocation tables.  That does not mean that they are supported or used on Windows, of course.  You know more about what is actually used in PE format files than I do.