foo/README.DK.md

# food / fooc — et stack-bufferoverløb, fra begge sider

Et C99-sikkerhedslaboratorium i to halvdele:

- **`food.c`** — en bevidst sårbar TCP-daemon. Den har et ægte,
  lærebogsagtigt stack-bufferoverløb (CWE-120) og et par fejl oveni.
- **`fooc.c`** — et exploit til den. Det beregner overflow-offsettet ved at
  disassemblere target-programmet ved kørsel, læser adresse-leaks fra daemonen
  og får en shell på "offeret" ved at overskrive en gemt returadresse.

Pointen er ikke shellen. Pointen er, at du kan følge med hele vejen, hvordan
en hukommelsessikkerhedsfejl bliver til vilkårlig kodeudførelse — og derefter
se præcist, hvilke modforanstaltninger der stopper hvert trin i den kæde. Hver
linje i begge programmer er kommenteret, fordi mekanismen er lektionen.

```
                   din terminal
                         |
                     ./fooc   (exploit)
                         |
                    TCP 127.0.0.1:2342
                         |
                     ./food   (sårbar daemon)
                         |
                 fork() -> vulnerable_handler() -> overflow -> ret -> din kode
```

---

## ⚠️ Læs dette først

**`food` er en bevidst ødelagt netværkstjeneste. Den binder kun til
`127.0.0.1`, og den standard er bevidst — lad den være der.**

- Kør den **ikke** på en maskine, du holder af, eller på noget med data på.
- Bind den **ikke** til `0.0.0.0` eller en rigtig netværksgrænseflade. Den er
  bevidst eksternt udnyttelig.
- At rette `fooc` mod en host, du ikke ejer eller ikke har skriftlig tilladelse
  til at teste, er en computerindbrudsforseelse i de fleste jurisdiktioner —
  også efter UK Computer Misuse Act og US Computer Fraud and Abuse Act.
- Den binder til en uprivilegeret port (>1024), så du behøver ikke root. Forbedr
  den ikke ved at tilføje capabilities eller køre den som systemtjeneste.
- Hver forbindelse håndteres i et `fork()`et barn, og `food` reaper det, så
  nedbrud hober sig ikke op. Hvis du bagefter finder dusinvis af strejfende
  `sh`-processer, er `pkill -x sh` oprydningen.

I tvivlstilfælde: Dette laboratorium er til en virtuel maskine eller container,
på et netværk du kontrollerer, på en maskine uden noget, du ville savne.

---

## Hurtig start

```sh
make            # bygger food, fooc og test-harnessene
make run        # starter food på 127.0.0.1:2342, frakoblet i baggrunden
make test       # kører alle tre exploit-teknikker
make stop       # stopper daemonen
```

Derefter i hånden:

```sh
./fooc -t leak        # se de adresse-leaks, food udleverer
./fooc -t demo -v     # send junk; se food dø med SIGSEGV
./fooc -t ret2win -i  # hop til en funktion, der allerede findes -> shell
```

### Krav

| Værktøj | Hvortil | Bemærkninger |
|---|---|---|
| `gcc` (eller clang) | bygning | C99. Testet med gcc 16.2 |
| `objdump` | `fooc` | binutils. `fooc` kalder det ved kørsel |
| `nasm` | `make verify` | kun til at krydstjekke shellcoden; springes over, hvis ikke til stede |
| `gdb` | `make debug` | valgfrit |
| Linux, x86-64 | begge | payload og gadget-jagt er arkitekturafhængige |

`fooc` har også brug for `-ldl` til `dlsym()`; Makefile'et klarer det.

---

## Fejlen

Én linje i `food.c` er hele angrebsfladen:

```c
char buf[FOOD_BUFSZ];                  /* 64 bytes  */
n = read(fd, buf, FOOD_READMAX);       /* op til 512 bytes fra netværket */
```

64 bytes destination, 512 bytes accepteret. Angriberen overskriver 448 bytes
forbi enden af bufferen, og fordi stacken vokser nedad, betyder "forbi enden"
"ind i det ovenstående frame" — og det er præcis der, den gemte
framepointer og den **gemte returadresse** ligger.

I en kompileret x86-64-funktion ved `-O0`:

```
  høje adresser
  +------------------------+  rbp + 16 : callerens lokale
  |  ...                   |
  +------------------------+  rbp +  8 : GEMT RETURADRESSE   <-- bliver til RIP
  |  saved rbp (8 bytes)   |
  +------------------------+  rbp      : vores framepointer
  |  line[128]             |
  |  buf[64]               |  <- rsp: det, read() fylder
  +------------------------+
  lave adresser
```

Når funktionen returnerer, popper `leave; ret` de 8 bytes ind i `RIP`, og CPU'en
hopper, hvor angriberen har bestemt. Alt andet i dette laboratorium er
aritmetik om, hvorhen der skal peges.

For denne build er tallene: `buf` er 64 bytes, det gemte `rbp` er 8, så
returadressen ligger på offset **88** fra starten af `buf`. `fooc` hardkoder
ikke det — det disassemblerer `food` og finder `lea -0x50(%rbp)` foran
`call read@plt`, så det fortsat virker, hvis du ændrer `FOOD_BUFSZ`.

> gcc fortæller dig allerede om det. At bygge `food` printer:
> `warning: 'read' writing 512 bytes into a region of size 64 overflows the
> destination [-Wstringop-overflow=]`. Undertryk aldrig den advarsel i ægte
> kode. Den er gratis sikkerhed.

---

## De tre teknikker

`fooc -t <technique>`. De står i den rækkefølge, en ægte angriber ville
arbejde sig igennem dem, fordi hver enkelt har brug for det, den forrige lærte
dig.

### 1. `ret2win` — kontrollér instruktionsmarkøren

```
[ 88 bytes junk ][ adressen på food's win() ]
                ^ saved rbp
                                 ^ bliver til RIP
```

`win()` er en funktion i target-programmet, der exec'er `/bin/sh`. At
overskrive returadressen med dens adresse er hele exploitet.

**Hvad det lærer:** du har vilkårlig kontrol over instruktionsmarkøren. Det
kræver heller ikke noget leak, fordi binærfilen er bygget `-no-pie`, så `win()`
sidder på en fast adresse for evigt.

**Den virkelige verdens ækvivalent** er ikke "angreb er nemme", men "skib ikke
udokumenterede bagdøre i netværks-binærfiler". Hvis en funktion som `win()`
findes i din binærfil, vil et bufferoverløb finde den. Det er bogstaveligt talt
Juniper ScreenOS-bagdør-CVE-klassen.

**Forsvar:** `-fPIE` (eller ASLR) randomiserer load-adressen, så angriberen må
kende adressen — hvilket som regel betyder, at de først har brug for et leak.
Derfor fejler `ret2win` mod `food_hardened`.

### 2. `ret2libc` — kald hvad som helst, ved navn

```
[ junk ][ pop rdi; ret ][ adressen på "/bin/sh" ][ adressen på system() ]
        ^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^    ^^^^^^^^^^^^^^^^^^^^^
        sætter rdi       strengen at sende      funktionen at kalde
```

Ved udførelse: `ret` popper `pop rdi; ret` ind i RIP; det popper
`"/bin/sh"`-pointeren ind i `RDI`; dets `ret` popper `system()` ind i RIP, mens
`RDI` stadig holder strengen. `system("/bin/sh")` kører.

Gadgets (`pop rdi; ret`) er ikke i `food` — denne glibc har intet
`__libc_csu_init` — så `fooc` finder dem ved at scanne live libc-hukommelse
efter byteparret `5f c3`. Det lokaliserer libc via `/proc/self/maps`, finder
offsets for `system` og `"/bin/sh"` med `dlsym()` og beregner basen ud fra det
leak, `food` offentliggør. Intet er hardkodet, så det overlever en
libc-opdatering.

**Hvad det lærer:** når du først kan kontrollere `RIP`, kan du kæde
*eksisterende* instruktioner sammen. Det er return-oriented programming, og det
er sådan næsten alle virkelige exploits ser ud, fordi det ikke kræver
angriberleveret eksekverbar hukommelse.

**Forsvar:** ingen af compiler-flagene stopper det alene. Det virker mod en
PIE-binærfil, med NX, med canary — så længe angriberen har et leak.
Forsvarene er "hav ikke overløbet" og "læk ikke adresser". Se tabellen nedenfor.

### 3. `shellcode` — kør din egen maskinkode

23 bytes, placeret i starten af bufferen, med `RIP` pegende på dem:

```asm
xor    esi, esi                    ; envp = NULL
xor    edx, edx                    ; argv = NULL
movabs rdi, 0x68732f6e69622f       ; rdi = "/bin/sh\0" som 8 rå bytes
push   rdi                         ; læg strengen på stacken
mov    rdi, rsp                    ; rdi = &"/bin/sh"
push   0x3b                        ; 59 = __NR_execve
pop    rax
syscall                           ; vi er nu en shell
```

Det er den reneste form for fejlen: angriberen leverer *instruktionerne*, ikke
bare adressen på instruktioner, der allerede findes. Ingen libc-offsets
nødvendige, så det virker i princippet mod et statisk linket, fuldt
randomiseret target.

`make verify` assemblerer `shellcode.S` og diff'er det mod byte-arrayet, der er
indlejret i `fooc.c`, så de to ikke kan drive fra hinanden.

**Forsvar:** **NX** (også kaldet W^X, "no execute"). At markere stacken som
ikke-eksekverbar får hardwaren til at nægte at hente instruktioner fra den, og
`ret`-et lander på en side, der ikke kan køre. Det er derfor `make food`
giver `-z execstack`: en normal Linux-stack er `rw-p`, ikke `rwx`, og teknikken
dør med SIGSEGV ved `RIP = payloadens adresse`. Den absolut vigtigste lektion i
laboratoriet er, at hver eneste af disse bytes kun virker, fordi compileren fik
besked på at lade stacken være eksekverbar. Det flag er tændt til gavn for
ingen.

### Også inkluderet

| Tilstand | Hvad den gør |
|---|---|
| `-t leak` | forbinder, printer leaks, sender intet |
| `-t demo` | sender `rip_off + 8` bytes `0x41`, så `RIP` bliver `0x4141...` og daemonen dør. Beviser fejlen helt uden adresseviden |
| `-t sled` | et ret-sled, bevidst beholdt som et **fejlende** eksempel. Uden et leak ville du brute-force ASLR ved at fylde bufferen med adressen på et `ret`. Det kan ikke virke her: `food` accepterer 512 bytes, så sleden har ~53 slots mod ~28 bit entropi. Implementeret, så du kan se det fejle og bekræfte, at mekanismen virkelig er "CPU'en følger en kæde af rets" |

---

## Tabellen over modforanstaltninger

Det er den del, man skal huske. Hver række er et ægte forsvar, og højre kolonne
viser, hvad den rent faktisk gør ved begivenhedskæden.

| Modforanstaltning | Sådan aktiveres | Hvad den stopper | Hvad den *ikke* stopper |
|---|---|---|---|
| **Begræns read** | `n = read(fd, buf, sizeof buf - 1);` | **Alt.** Fejlen findes ikke, så intet nedstrøms betyder noget | Intet — det er den eneste fuldstændige fix |
| **Stack-canary** | `-fstack-protector-strong` (gccs standard) | `ret`-et: canaryen tjekkes ved funktionens afslutning, så smadringen opdages, og processen abort'er, før `RIP` poppes | En fejl i en funktion *uden* array (intet at beskytte); et overflow, der holder sig under canaryen; alt, der ikke returnerer normalt |
| **NX / W^X** | `-z noexecstack` (standarden) | Shellcode. Payloadens egne instruktioner kan ikke hentes | ret2win og ret2libc fuldstændigt. De er *grunden* til, at ROP findes |
| **PIE + ASLR** | `-fPIE` + ASLR=2 (begge standard) | ret2wins hardkodede adresser. Alt flytter sig ved hver kørsel | Alt, hvor angriberen har et leak. ASLR hæver prisen på et exploit; det er ikke en fix. Bemærk, at stack, heap og mmap randomiseres, men hoved-binærfilens *indhold* gør ikke — det er det, ROP-kæder bruger |
| **Læk ikke** | ingen `printf("%p")` til klienter; initialisér før du printer | Det informationsleak, der gør ASLR til "gratis" i stedet for "dyrt" | — |
| **Brug ikke `printf(user_data)`** | `printf("%s", buf)` i stedet for `printf(buf)` | Format-string-fejl: `%x`-stack-reads, `%n`-vilkårlige skrivninger, hvilket er en *anden* vej til RCE | — |
| **Brug ikke utroverdige stier** | validér og `openat()` under en fast mappe | Sti-traversal (CWE-22) | — |
| **CET / shadow stack** | `-fcf-protection=full`, kernel- og CPU-understøttelse | `ret`-et selv: shadow stacken husker den *rigtige* returadresse og fault'er ved mismatch. Fanger ROP-kæder, der bruger hardware-`ret` | Angreb, der aldrig `ret` (call-oriented, eller at overskrive en funktionspegers mål med en gadget-kæde, der ikke behøver en retur) |
| **Sikre sprog** | Rust, Go, C# til ny kode | Hele klassen. Bounds-tjek udføres ved kørsel, ikke håbet på ved review | — |

### Se det selv

```sh
make run            # sårbar daemon
make test           # alle tre teknikker virker

make test-hardened  # samme kildekode, modforanstaltninger på
```

`test-hardened` bygger `food_hardened` med `-fstack-protector-strong -fPIE -pie
-z noexecstack`, bytter den ind, kører alle tre igen og lægger derefter den
sårbare tilbage. Du vil se:

```
### stack segment: 'rw-p' (NOT executable) is what you want to see
--- ret2win   was stopped by the mitigations (as expected)
--- ret2libc  was stopped by the mitigations (as expected)
--- shellcode was stopped by the mitigations (as expected)
```

Og i den hærdede daemons log, canaryen der udløses:

```
*** stack smashing detected ***: terminated
```

Læs det grundigt, for det er den vigtigste linje i hele laboratoriet: **canaryen
fangede ret2win, ikke PIE.** Alle tre teknikker dør ved canaryen, fordi alle tre
går gennem det samme `read()` og smadrer den samme frame. NX stopper kun
yderligere shellcodens *kode*; PIE bryder kun yderligere den hardkodede adresse.
Tænd dem enkeltvis, og du vil opdage, at de fleste enkelte modforanstaltninger
efterlader dig udsat over for noget.

---

## Filer

| Fil | Formål |
|---|---|
| `food.c` | den sårbare daemon. 6 nummererede fejl, hver med sin fix i kommentaren |
| `fooc.c` | exploitet. objdump-baseret offseterkendelse, `/proc`-baseret libc-erkendelse, 4 payload-buildere |
| `shellcode.S` | de 23 shellcode-bytes som assembly, så de kan læses og verificeres. `fooc` bærer dem inline og behøver ikke dette ved kørsel |
| `Makefile` | bygger, tester og den hærdede sammenligning |
| `tests/pty_test.c` | driver `fooc` gennem et pseudo-terminal og tjekker for ægte shell-output |
| `tests/sock_test.c` | uafhængig verifikator over en rå socket, så resultatet ikke afhænger af `fooc` |
| `food.log` | daemonens log. Dit bevis på, hvad der skete |

---

## To fejl i dette laboratorium, der er værd at forstå

Det er ikke target-programmets fejl. Det er fejl i exploitet og i dets
test-harness, og begge producerede overbevisende løgne. De er dokumenteret i
kilden, hvor de bor; her står de, fordi fiaskomønstrene er lærerige.

### Stack-justering: nedbruddet, der ikke er en NULL-dereference

**Symptom.** Kapringen lander korrekt — `gdb` viser dig i `win()` — og så dør
det allerførste, `win()` gør, et `dprintf()`. `SIGSEGV`-handleren rapporterer
`RIP` dybt inde i glibcs formatter og en fejladresse på `(nil)`, hvilket ser
præcis ud som en korrupt pointer.

**Årsag.** System V AMD64-ABI'en kræver 16-byte stack-justering. Et normalt
`ret` genskaber `%rsp` præcis som det tilsvarende `call` gemte det, så
invarianten bevares gratis. Vores nøgne `ret` gør ikke: efter det gælder
`%rsp = buf + rip_off`. Her er `buf` 16-byte justeret og `rip_off` er 88, så
callee'en får en stack, der er 8 mod 16. glibc er kompileret med SSE2, og
`movaps` **fault'er** ved et fejljusteret operand. På x86 rejser det `#GP`, ikke
`#PF`, så kernen har ingen fejladresse og rapporterer `si_addr = 0`. Det NULL
er fingerpeg: en justeringsfejl forklædt som en NULL-dereference.

**Fix.** Et `ret`-gadget *ved offset `rip_off`*, der flytter det rigtige target
8 bytes op, fordi hvert `ret` lægger præcis 8 til `%rsp`. Rækkefølgen er
kritisk: en tidligere version hæftede `ret`-et *efter* target og producerede
`[ padding | target | ret ]`, hvor det afsluttende `ret` aldrig nås, og fixen
stille og roligt intet gør. Et vildfarent `ret`, der ligner en fejl, er næsten
altid bevidst.

### Én socket, to læsere: det byte, der forsvandt

**Symptom.** Shellcode blev rapporteret som fungerende. Derefter blev
pty-harnessen gjort strengere (slukning af `ECHO`, så terminalen holdt op med at
ekko harnessens egen kommandolinje tilbage til sig selv), og teknikken begyndte
at fejle. Dybere set tabte hver teknik præcis ét byte fra starten af hver
udgangschunk: `uid=1000(hanez)` blev printet som `id=1000(hanez)`, `PWNED-OK`
som `WNED-OK`, `Linux 7.2.7` som `inux 7.2.7`.

**Årsag.** `fooc` plejede at `dup2()`e socket'en på sit eget stdin/stdout og
`execv()`e en *lokal* `/bin/sh`, mens et forket relay-barn også læste den samme
socket for at flytte output til terminalen. Kernen er ligeglad med, at de to
samarbejder. En streamsocket har **én** læse-cursor, og hver læser flytter den,
så bytes deles uforudsigeligt mellem dem. Den lokale shell, der er en
interaktiv login-shell, læste præcis ét byte og smed det væk — hver eneste
gang. `strace -f` viste det øjeblikkeligt:

```
read(0, "u", 1)                              <- den lokale shell, æder et byte
read(4, "id=1000(hanez) gid=1000(hanez) g".., 310)   <- relay'et, 1 byte for kort
```

**Fix.** Der er slet ingen shell på denne side. Der er præcis én shell i hele
billedet, og den er på offeret, inde i den kaprede proces, med
TCP-forbindelsen som dens stdin/stdout. Denne side flytter kun bytes. Hvis du
nogensinde har brug for to forbrugere af en stream, skal den stream have én
eneste læser, der bevidst demultiplekser den.

**Meta-lektionen.** Det første "fungerende" resultat var et falsk positivt,
produceret af at pty'en ekkoede harnessens egen kommandolinje tilbage til den,
og fixen for det falske positive er det, der afslørede den rigtige fejl. Tests,
der ikke kan fejle, er værre end ingen tests, fordi de forvandler "jeg ved
ikke" til "det virker". En test-harness fortjener samme mistænksomhed som den
kode, den tester.

---

## At pille ved det

Ting, der er værd at prøve, nogenlunde i den rækkefølge, du lærer mest af dem:

1. **Ændr `FOOD_BUFSZ` til 128.** Kør `fooc` igen. Det burde stadig virke uden
   ændringer, fordi det læser offset ud af disassembly'en. Bræk det så i
   hånden — hardkod 88 — og se det crashe. Tilføj derefter et andet array
   mellem `buf` og de gemte registre, og se den automatiske erkendelse klare
   det.

2. **Tilføj `-Wformat-security` og se, hvad format-string-stien gør.** Send
   `%p %p %p %n` og se `food` lække stacken.

3. **Brug gdb.** `make debug`, derefter:
   ```gdb
   (gdb) break food.c:393        # det read(), der løber over
   (gdb) run -p 2342
   (gdb) info registers rsp rbp
   (gdb) x/24gx $rsp             # bemærk, hvor returadressen ligger
   (gdb) c                        # i et andet terminal: ./fooc -t ret2win
   ```
   `SIGSEGV`-handleren logger `REG_RIP` og `REG_RSP`, så `food.log` fortæller
   dig, om kapringen landede, selv når barnet dør, før du kan koble på.

4. **Slet justeringsfixen** i `fooc.c` og se `#GP`-fejlen med
   `si_addr = 0`-signaturen. Læs derefter `/proc/sys/kernel/randomize_va_space`
   og tænk over, hvad ASLR randomiserer, og hvad det ikke gør.

5. **Bræk libc-symbolopløsningen** og se `fooc` tilpasse sig. Hele pointen med
   `/proc/self/maps`-tilgangen er, at intet offset er hardkodet.

6. **Skriv en fjerde teknik.** En `ret2csu`-lignende kæde, hvis du kan finde
   `__libc_csu_init`, eller en SROP-kæde (`sigreturn`-frames lader dig
   kontrollere alle registre på én gang). Begge er rent ROP og behøver ingen
   eksekverbar hukommelse.

7. **Fix `food.c` ordentligt**, én fejl ad gangen, og kør exploitet igen efter
   hver fix. Rækkefølgen i tabellen øverst i `food.c` er nogenlunde den rigtige
   rækkefølge at tænke i: begræns først read'et, for intet andet betyder noget,
   før fejlen er væk.

---

## Oprydning

```sh
make stop        # stopper food
make clean       # fjerner build-produkter; lader food.log være i fred
pkill -x sh      # kun hvis du har strejfende shells fra en test, der gik skævt
```

Bemærk: `pkill -x food` matcher proces**navnet** præcist. Brug ikke
`pkill -f ./food` — det mønster matcher også den shell, du har skrevet det i,
og dræber din egen session. Det er ikke en hypotese; det skete, mens dette
laboratorium blev bygget.