Re: #define of 'extern' in stackgap.c

On 16 March 2016 at 15:30, Felix von Leitner <[email protected]> wrote:
> The root problem is that statically linked ELF programs are loaded at a
> fixed address. This is an ELF restriction. However, it is also possible
> to have an ELF shared object (usually a shared library) and load that
> like a regular binary. Then the kernel can load it at a random address,
> which is good for security.
>
> [...]
>
> However, having a shared library has its own problems. Most importantly,
> it has an ELF interpreter (ld.so) that does the relocations. The main
> benefit of using dietlibc is that the binaries are self contained, so
> having an ld.so is out.

Well, you can have both -- an ET_DYN binary (i.e. PIE) without the
need to have a runtime linker. Just link with -shared instead of -pie.

$ gcc -nostdlib -fPIE -shared -m32 -O2 -o maps maps.c
$ ./maps
f7723000-f7724000 r-xp 00000000 00:00 0                                  [vdso]
f7724000-f7725000 r-xp 00000000 fe:00 96503362
  /home2/krause/maps
f7725000-f7726000 rw-p 00000000 fe:00 96503362
  /home2/krause/maps
fff69000-fff8b000 rw-p 00000000 00:00 0                                  [stack]
$ readelf -l maps

Elf file type is DYN (Shared object file)
Entry point 0x1c0
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x002ac 0x002ac R E 0x1000
  LOAD           0x0002ac 0x000012ac 0x000012ac 0x0006c 0x00474 RW  0x1000
  DYNAMIC        0x0002ac 0x000012ac 0x000012ac 0x00060 0x00060 RW  0x4
  NOTE           0x0000d4 0x000000d4 0x000000d4 0x00024 0x00024 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.build-id .hash .gnu.hash .dynsym .dynstr .text .rodata
   01     .dynamic .got.plt .bss
   02     .dynamic
   03     .note.gnu.build-id
   04

So maps[1] has no interpreter and is a PIE binary that has all its
mappings randomized by the kernel. Just what you said is not possible,
no?

Cheers,
Mathias

[1] http://ld-linux.so/~minipli/stuff/maps.c