Jaka jest opcja -fPIE dla plików wykonywalnych niezależnych od pozycji w gcc i ld?

Jak zmieni kod, np. Wywołania funkcji?

PIE ma obsługiwać randomizację układu przestrzeni adresowej (ASLR) w plikach wykonywalnych.

Przed utworzeniem trybu PIE, pliku wykonywalnego programu nie można było umieścić pod losowym adresem w pamięci, tylko biblioteki dynamiczne z kodem niezależnym od pozycji (PIC) mogły zostać przeniesione do losowego przesunięcia. Działa bardzo podobnie do tego, co robi PIC dla bibliotek dynamicznych, różnica polega na tym, że nie jest tworzona tabela łączenia procedur (PLT), zamiast tego używana jest relokacja względem komputera.

Po włączeniu obsługi PIE w gcc / linkers, treść programu jest kompilowana i linkowana jako kod niezależny od pozycji. Dynamiczny linker wykonuje pełne przetwarzanie relokacji w module programu, podobnie jak biblioteki dynamiczne. Jakiekolwiek użycie danych globalnych jest konwertowane w celu uzyskania dostępu za pośrednictwem tabeli globalnych przesunięć (GOT) i dodawane są relokacje GOT.

PIE jest dobrze opisana w tej prezentacji OpenBSD PIE .

Zmiany funkcji są pokazane na tym slajdzie (PIE vs PIC).

x86 pic vs ciasto

Lokalne zmienne globalne i funkcje są zoptymalizowane w postaci kołowej

Zewnętrzne zmienne globalne i funkcje są takie same jak na rys

i na tym slajdzie (SROKA a linkowanie w starym stylu)

x86 pie vs no-flags (naprawione)

Lokalne zmienne i funkcje globalne są podobne do stałych

Zewnętrzne zmienne globalne i funkcje są takie same jak na rys

Należy pamiętać, że PIE może być niezgodne z -static

Minimalny działający przykład: GDB plik wykonywalny dwukrotnie

Dla tych, którzy chcą zobaczyć jakąś akcję, zobaczmy, jak ASLR działa na pliku wykonywalnym PIE i zmienia adresy między uruchomieniami:

main.c

#include <stdio.h>

int main(void) {
    puts("hello");
}

main.sh

#!/usr/bin/env bash
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
for pie in no-pie pie; do
  exe="${pie}.out"
  gcc -O0 -std=c99 "-${pie}" "-f${pie}" -ggdb3 -o "$exe" main.c
  gdb -batch -nh \
    -ex 'set disable-randomization off' \
    -ex 'break main' \
    -ex 'run' \
    -ex 'printf "pc = 0x%llx\n", (long  long unsigned)$pc' \
    -ex 'run' \
    -ex 'printf "pc = 0x%llx\n", (long  long unsigned)$pc' \
    "./$exe" \
  ;
  echo
  echo
done

Dla kogoś z -no-piewszystkim jest nudno:

Breakpoint 1 at 0x401126: file main.c, line 4.

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x401126

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x401126

Przed rozpoczęciem wykonywania break mainustawia punkt przerwania na 0x401126.

Następnie podczas obu egzekucji runzatrzymuje się pod adresem 0x401126.

Ten z -piejednak jest znacznie bardziej interesujący:

Breakpoint 1 at 0x1139: file main.c, line 4.

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x5630df2d6139

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x55763ab2e139

Przed przystąpieniem do wykonania, GDB zajmuje tylko „atrapę” adres, który jest obecny w pliku wykonywalnego: 0x1139.

Jednak po uruchomieniu GDB inteligentnie zauważa, że ​​dynamiczny moduł ładujący umieścił program w innym miejscu, a pierwsza przerwa zatrzymała się na 0x5630df2d6139.

Następnie drugi przebieg również inteligentnie zauważył, że plik wykonywalny ponownie się poruszył i zakończył się przerwaniem 0x55763ab2e139.

echo 2 | sudo tee /proc/sys/kernel/randomize_va_spacezapewnia, że ​​ASLR jest włączony (ustawienie domyślne w Ubuntu 17.10): Jak mogę tymczasowo wyłączyć ASLR (randomizacja układu przestrzeni adresowej)? | Zapytaj Ubuntu .

set disable-randomization offjest potrzebne, w przeciwnym razie GDB, jak sugeruje nazwa, domyślnie wyłącza ASLR dla procesu, aby nadawać stałe adresy w przebiegach, aby poprawić wrażenia z debugowania: Różnica między adresami gdb a adresami „rzeczywistymi”? | Przepełnienie stosu .

readelf analiza

Ponadto możemy również zauważyć, że:

readelf -s ./no-pie.out | grep main

podaje rzeczywisty adres ładowania środowiska uruchomieniowego (pc wskazał następującą instrukcję 4 bajty dalej):

64: 0000000000401122    21 FUNC    GLOBAL DEFAULT   13 main

podczas:

readelf -s ./pie.out | grep main

daje tylko przesunięcie:

65: 0000000000001135    23 FUNC    GLOBAL DEFAULT   14 main

Wyłączając ASLR (za pomocą jednego randomize_va_spacelub set disable-randomization offdrugiego), GDB zawsze podaje mainadres 0x5555555547a9:, więc wnioskujemy, że -pieadres składa się z:

0x555555554000 + random offset + symbol offset (79a)

TODO, gdzie jest na stałe zakodowany kod 0x555555554000 w jądrze Linux / programie ładującym glibc / gdziekolwiek? Jak jest określany adres sekcji tekstowej pliku wykonywalnego PIE w systemie Linux?

Minimalny przykład montażu

Kolejną fajną rzeczą, którą możemy zrobić, jest pobawienie się kodem asemblera, aby bardziej konkretnie zrozumieć, co oznacza PIE.

Możemy to zrobić za pomocą wolnostojącego zestawu Linux x86_64 hello world:

sieć elektryczna

.text
.global _start
_start:
asm_main_after_prologue:
    /* write */
    mov $1, %rax   /* syscall number */
    mov $1, %rdi   /* stdout */
    mov $msg, %rsi  /* buffer */
    mov $len, %rdx /* len */
    syscall

    /* exit */
    mov $60, %rax   /* syscall number */
    mov $0, %rdi    /* exit status */
    syscall
msg:
    .ascii "hello\n"
len = . - msg

GitHub upstream

i łączy się i działa dobrze z:

as -o main.o main.S
ld -o main.out main.o
./main.out

Jeśli jednak spróbujemy połączyć go jako PIE z ( --no-dynamic-linkerjest to wymagane, jak wyjaśniono w: Jak utworzyć statycznie powiązany plik wykonywalny niezależny od pozycji w systemie Linux? ):

ld --no-dynamic-linker -pie -o main.out main.o

wtedy połączenie zakończy się niepowodzeniem z:

ld: main.o: relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC
ld: final link failed: nonrepresentable section on output

Ponieważ linia:

mov $msg, %rsi  /* buffer */

koduje na stałe adres komunikatu w movoperandzie i dlatego nie jest niezależny od pozycji.

Jeśli zamiast tego napiszemy to w sposób niezależny od pozycji:

lea msg(%rip), %rsi

wtedy łącze PIE działa dobrze, a GDB pokazuje nam, że plik wykonywalny jest ładowany za każdym razem w innym miejscu w pamięci.

Różnica polega na tym, że leazakodował adres msgwzględny w stosunku do bieżącego adresu komputera ze względu na ripskładnię, zobacz także: Jak używać adresowania względnego RIP w 64-bitowym programie asemblerowym?

Możemy to również ustalić, demontując obie wersje za pomocą:

objdump -S main.o

które dają odpowiednio:

e:   48 c7 c6 00 00 00 00    mov    $0x0,%rsi
e:   48 8d 35 19 00 00 00    lea    0x19(%rip),%rsi        # 2e <msg>

000000000000002e <msg>:
  2e:   68 65 6c 6c 6f          pushq  $0x6f6c6c65

Widzimy więc wyraźnie, że leama już pełny poprawny adres msgzakodowany jako aktualny adres + 0x19.

movWersja jednak ustawił adres, na 00 00 00 00, co oznacza, że przeniesienie będą tam wykonywane: Czego łączniki zrobić? Tajemniczy R_X86_64_32Swld komunikacie o błędzie jest rzeczywisty typ relokacji, który był wymagany i który nie może mieć miejsca w plikach wykonywalnych PIE.

Kolejną zabawną rzeczą, którą możemy zrobić, jest umieszczenie msgw sekcji danych zamiast .text:

.data
msg:
    .ascii "hello\n"
len = . - msg

Teraz .ozbiera się, aby:

e:   48 8d 35 00 00 00 00    lea    0x0(%rip),%rsi        # 15 <_start+0x15>

więc offset RIP wynosi teraz 0i domyślamy się, że asembler zażądał relokacji. Potwierdzamy to:

readelf -r main.o

co daje:

Relocation section '.rela.text' at offset 0x160 contains 1 entry:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000011  000200000002 R_X86_64_PC32     0000000000000000 .data - 4

tak oczywiste R_X86_64_PC32jest relokacja względna komputera, która ldmoże obsłużyć pliki wykonywalne PIE.

Ten eksperyment nauczył nas, że sam linker sprawdza, czy program może być SROKĄ i oznacza go jako taki.

Następnie podczas kompilacji z GCC -pie mówi GCC, aby wygenerował niezależny montaż pozycji.

Ale jeśli sami piszemy assembler, musimy ręcznie upewnić się, że osiągnęliśmy niezależność pozycji.

W ARMv8 aarch64 niezależną pozycję hello world można uzyskać za pomocą instrukcji ADR .

Jak ustalić, czy ELF jest niezależny od pozycji?

Oprócz uruchamiania go przez GDB, niektóre metody statyczne są wymienione na:

• plik wykonywalny: /unix/89211/how-to-test-whether-a-linux-binary-was-compiled-as-position-independent-code/435038#435038
• biblioteka: Jak mogę stwierdzić, używając czegoś takiego jak objdump, czy plik obiektowy został zbudowany przy użyciu -fPIC?

Testowane w Ubuntu 18.10.