Re: A Famous Security Bug

On 25/03/2024 17:06, bart 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.
 If I take this C program:
      #include <stdio.h>
     int main(void) {
         printf("%p\n", main);
     }
 This shows 0000000000401000 when compiled with mcc or tcc, or 0000000000401020 with lccwin32 (the exact address of 'main' relative to the image base will vary). With DMC (32 bits) it's 0040210. All load at 0x400000.
 With gcc, it shows: 00007ff6e63a1591.
 Dynamic loading can be disabled by passing --disable-dynamicbase to ld, then it might show something like 0000000140001000, which corresponds to the default Image Base file in the EXE header
 Not dynamic, but still high.
 (My compilers, both for C and M, did not generate code suitable for high-loading until a few months ago. That didn't matter since the EXEs loaded at the fixed 0x400000 adddress. But it can matter for DLL files and will do for OBJ files, since the latter would need to use an external linker.
 So if I do this with a mix of mcc and gcc:
    C:\c>mcc test -c
   Compiling test.c to test.obj
    C:\c>gcc test.obj
    C:\c>a
   00007FF613311540
 I get the same high-loaded address. I don't think that Tiny C has that support yet for high-loading code.)
 To summarise: the high-loading is not directly to do with compilers, but the program that generates the EXE. But the compiler does need to generate code that could be loaded high if needed.

Thanks for that explanation - it fills in some blanks in my understanding.