Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #384022
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: A Famous Security Bug |
| Date | 2024-03-26 01:31 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <20240326023103.00004ea0@yahoo.com> (permalink) |
| References | (14 earlier) <uts7e0$1686i$1@dont-email.me> <20240325195118.0000333a@yahoo.com> <utsemf$18477$1@dont-email.me> <20240326000501.00007d6d@yahoo.com> <utsq47$1atlm$1@dont-email.me> |
On Mon, 25 Mar 2024 21:25:27 +0000
bart <bc@freeuk.com> wrote:
> On 25/03/2024 21:05, Michael S wrote:
> > On Mon, 25 Mar 2024 18:10:23 +0000
> > bart <bc@freeuk.com> 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.
> >>
> >
> > 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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-20 18:54 +0000
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-20 19:38 +0000
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-20 14:20 -0700
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-20 14:23 -0700
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-21 16:13 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-21 17:41 +0000
Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-21 12:37 -0700
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-21 20:21 +0000
Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-21 14:31 -0700
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-21 23:19 +0000
Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-21 17:38 -0700
Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-22 12:39 -0700
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-21 13:46 -0700
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 15:50 +0000
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-22 09:31 -0700
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 17:20 +0000
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:38 -0400
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 19:27 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 19:13 +0100
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-22 11:21 -0700
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 19:43 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 16:36 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 16:07 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 18:58 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-24 01:23 +0000
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-23 12:51 -0400
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-24 05:50 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 14:21 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-24 16:02 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 17:27 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-27 21:06 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-28 19:07 +0100
Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-24 12:45 -0700
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:05 -0400
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 18:42 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 18:55 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 21:26 +0100
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 12:35 -0400
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 17:28 +0000
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:38 -0400
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 13:51 +0100
Re: A Famous Security Bug Anton Shepelev <anton.txt@gmail.moc> - 2024-03-21 21:13 +0300
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-21 12:42 -0700
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-21 20:21 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 14:38 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 15:33 +0000
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:15 -0400
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 18:50 +0100
Re: A Famous Security Bug Richard Kettlewell <invalid@invalid.invalid> - 2024-03-23 09:20 +0000
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 16:06 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 17:08 +0100
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 16:56 +0000
Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-24 09:45 -0700
Re: A Famous Security Bug Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-24 17:53 +0000
Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-17 12:10 -0700
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-04-18 10:20 +0200
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-04-18 14:26 -0700
Re: A Famous Security Bug Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-03-28 12:23 +0300
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-28 14:12 +0000
Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-22 07:50 -0700
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:14 -0400
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-22 21:41 +0000
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-22 16:30 -0700
Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 00:09 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 17:25 +0100
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-23 16:51 +0000
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-23 19:58 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 14:42 +0100
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-23 03:26 -0400
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-23 11:26 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 17:51 +0100
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-23 21:21 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 15:52 +0100
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 19:56 +0000
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-24 13:49 -0700
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 23:38 +0100
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 01:42 +0300
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 09:37 +0100
Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-25 08:54 -0700
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 23:07 +0000
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 01:39 +0200
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 02:12 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 09:58 +0100
Re: A Famous Security Bug Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-25 13:26 +0000
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 15:43 +0200
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-25 17:21 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 09:53 +0100
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-25 17:24 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 23:43 +0100
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 13:16 +0200
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 13:26 +0100
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 15:11 +0200
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 16:30 +0100
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 16:39 +0000
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 16:06 +0000
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 18:51 +0200
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 18:10 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 21:01 +0100
Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-25 20:28 +0000
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 23:05 +0200
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 21:25 +0000
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-26 01:31 +0200
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-26 00:34 +0000
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 19:07 +0100
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 18:53 +0300
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 18:58 +0000
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 13:04 +0200
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 13:24 +0200
Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 16:17 +0100
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-28 06:14 -0400
Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-23 11:44 -0700
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 17:22 +0300
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 17:26 +0300
Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 19:12 +0000
Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 22:33 +0300
Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-28 05:52 -0400
csiph-web