305 lines
No EOL
14 KiB
Markdown
305 lines
No EOL
14 KiB
Markdown
# The `wosuid` lab — root RCE with **no** setuid bit
|
||
|
||
```
|
||
foowosd an intentionally vulnerable daemon that is root because it was
|
||
*STARTED* as root (port 2344, loopback-only by default)
|
||
foowosc the exploit: turns a stack overflow into a **root** shell by
|
||
executing shellcode — same 23 bytes that pwned the user-level
|
||
`food` daemon in the parent lab
|
||
```
|
||
|
||
This is the third lab in the series. Same exploit toolchain, same style, one
|
||
fundamental difference:
|
||
|
||
| lab | how the target process becomes root | `uid=0(root)` shell? |
|
||
|----------|------------------------------------------------|----------------------|
|
||
| food/fooc| never — it is a plain user daemon | no |
|
||
| foosd/foosc | the SUID bit (`chmod u+s`) — euid 0, ruid 1000 | yes (needs `setreuid` in the shellcode, because bash resets euid→ruid) |
|
||
| **foowosd/foowosc** | **none — root *starts* the daemon** (sudo / systemd `User=root`) | **yes (plain `execve` shellcode)** |
|
||
|
||
The setuid bit is a *transfer vehicle* for privilege — not the privilege
|
||
itself. A daemon launched by root has real, effective and saved uid all equal
|
||
to 0. To the kernel that is root, period; it cannot and does not care whether
|
||
the process got there via `+s` on a file or via `sudo ./foowosd`. So the
|
||
overflow in a root-started daemon is a root exploit — *"I don't have SUID
|
||
binaries" is not the same as "I am not exploitable".*
|
||
|
||
That is the whole lesson of this lab. Everything below is the machinery.
|
||
|
||
---
|
||
|
||
## Quick start (what the user requested)
|
||
|
||
```
|
||
cd wosuid
|
||
make # build the daemon, the exploit, and the test harness
|
||
```
|
||
|
||
### The real thing — run the daemon as **root**
|
||
|
||
```
|
||
sudo make run-root # starts foowosd as uid 0 (process, not file mode)
|
||
make test-root # every technique must now yield uid=0(root)
|
||
```
|
||
|
||
### No sudo? The identical kernel path via a user namespace
|
||
|
||
```
|
||
make run-root-ns # uid 0 inside a user namespace — no password needed
|
||
make test-root # same verdicts; used by CI and anyone without sudo
|
||
```
|
||
|
||
### Baseline — daemon as your normal user (no root anywhere)
|
||
|
||
```
|
||
make run # foowosd runs with your uids
|
||
make test # exploits land shells, but `root` is expected MISSING
|
||
```
|
||
|
||
### Cleanup ritual (always: this is a root-shell lab)
|
||
|
||
```
|
||
make stop
|
||
```
|
||
|
||
`foowosd` is *not* setuid and nothing in this directory ever chmods `+s` —
|
||
that is the point. The dangerous state is the **process**, not the file.
|
||
|
||
---
|
||
|
||
## When you are told to set the SUID bit
|
||
|
||
You are **not** going to. This lab deliberately has no SUID bit:
|
||
|
||
- `foowosd` is built, owned and mode-regular like any other program.
|
||
- It becomes root the way real daemons do — by being *started* by root.
|
||
- `make run-root` uses `sudo` for exactly that, and `make run-root-ns` gets
|
||
a genuinely uid-0 process without any of it.
|
||
|
||
The suid bit belongs to the *sibling* lab (`foosd`). The contrast between the
|
||
two is the syllabus:
|
||
|
||
1. SUID lab: the bit gives **euid 0 but ruid 1000** → `execve("/bin/sh")` is
|
||
demoted by bash's guard (`euid != ruid` → reset) → shellcode must call
|
||
`setreuid(0,0)` first (32-byte payload).
|
||
2. This lab: root **starts** the process → **ruid == euid == 0** → the guard
|
||
has nothing to reset → the plain 23-byte `execve` shellcode keeps root.
|
||
|
||
Same overflow. Same technique. Different *origin* of privilege, different
|
||
payload shape. That is the lesson in miniature.
|
||
|
||
---
|
||
|
||
## The protocol
|
||
|
||
Whatever kind of client connects, foowosd greets it with:
|
||
|
||
```
|
||
FOOWOSD 1.0 ids=0/0 leak stack=0x7ffd… libc=0x7f… (the banner + leaks)
|
||
BUF=0x7ffd… (the buffer address)
|
||
```
|
||
|
||
`ids=euid/ruid` is the *"am I root?"* side-channel. foowosc prints a loud
|
||
warning when euid is not 0 (i.e. you started the daemon as a plain user): the
|
||
payload will still land, but the shell will be a user shell, and calling the
|
||
exploit "broken" would be wrong — it is merely not escalating.
|
||
|
||
> Spelling note: `ids=`, not `euid=`/`ruid=`. The test harness proves a live
|
||
> `id` ran by matching the literal `uid=NNN(` shape, so the banner must never
|
||
> contain a substring that itself satisfies the check. (In the SUID lab this
|
||
> exact trap produced a spectacular false positive.)
|
||
|
||
---
|
||
|
||
## The exploit techniques (`foowosc -t …`)
|
||
|
||
All four exploit paths below work against foowosd. When the daemon is root,
|
||
**all four that spawn anything yield root** — unlike the SUID lab, where
|
||
ret2win/ret2libc were quietly demoted to uid 1000 by bash's guard. Here there
|
||
is no mismatch to guard against.
|
||
|
||
| `-t` | what happens | when daemon is root |
|
||
|---------------|---------------------------------------------------------------------|---------------------|
|
||
| `shellcode` | 23-byte `execve("/bin/sh", NULL, NULL)` runs on the stack. | **root shell** (default) |
|
||
| `ret2win` | jump to `win()` → `execl("/bin/sh")` | **root shell** |
|
||
| `ret2libc` | ROP: `pop rdi; ret` → `"/bin/sh"` → `system()` | **root shell** |
|
||
| `demo` | junk overflow only — expect a SIGSEGV in the daemon log | crash, by design |
|
||
| `leak` | just print the leaks, send no payload | n/a |
|
||
|
||
```
|
||
./foowosc -t shellcode # interactive; default target 127.0.0.1:2344
|
||
./foowosc -t shellcode -n # send and report, no interactive session
|
||
```
|
||
|
||
A successful interactive session relays your terminal to the shell *on the
|
||
victim* — there is exactly one shell in the picture, and it is `/bin/sh`
|
||
running as root inside foowosd. Type `id` to see `uid=0(root)`.
|
||
|
||
### Why there is no `ret2win-root` technique here
|
||
|
||
foosc had one — it jumped to a `win_root()` that called `setreuid(0,0)`
|
||
before exec, because a setuid process ran with a real uid that still said
|
||
1000. A root-*started* process has real uid 0 already; there is nothing to
|
||
clear, so the extra function and technique would be teaching nothing.
|
||
Removed.
|
||
|
||
---
|
||
|
||
## What foowosc does, step by step
|
||
|
||
1. **Static analysis** — `objdump -d` of `./foowosd`. Finds
|
||
`vulnerable_handler`, `win()`, the `lea -0x50(%rbp)` that addresses `buf`,
|
||
and the first bare `ret`. From the displacement it computes
|
||
`rip_off = 80 + 8 = 88`. Nothing is hardcoded; this survives a rebuild.
|
||
2. **Self-introspection** — reads its own `/proc/self/maps` and `dlsym()`s
|
||
`system`/`read` to learn libc *offsets*. The target's libc base is
|
||
`leaked_read − off_read`, then `system = base + off_system`, and so on.
|
||
This delta-arithmetic is why exploits stay alive across libc versions.
|
||
3. **Connect** — reads the banner/leaks (`ids=`, `stack=`, `libc=`, `BUF=`).
|
||
4. **Build the payload** — for `shellcode`: 23 bytes of machine code, padding
|
||
to `rip_off`, then the saved RIP = `buf` (so `ret` jumps onto the code).
|
||
For `ret2win`/`ret2libc`: addresses computed from analysis — no execution
|
||
of the stack needed.
|
||
5. **The alignment fix** — a hijacked bare `ret` hands the callee `rsp ≡ 8
|
||
(mod 16)`, and glibc's SSE2 code `movaps`-faults on a misaligned stack (the
|
||
crash reporter logs `si_addr=(nil)` — the tell). foowosc inserts one extra
|
||
`ret` gadget before the real target, restoring the invariant. Kid-gloves
|
||
engineering in a shellcode lab, but it is the difference between a payload
|
||
that "sometimes works" and one that always works.
|
||
6. **Send, then relay** — the victim process *is* the shell; this process only
|
||
splices bytes. No local shell, no second reader — the single-read-cursor
|
||
failure (one byte eaten off every chunk) is documented in `become_shell()`.
|
||
|
||
---
|
||
|
||
## The daemon's deliberate bugs (all in `foowosd.c`, all real CWE classes)
|
||
|
||
| # | bug | CWE | note |
|
||
|---|-----|-----|------|
|
||
| 1 | `read(fd, buf, 512)` into a 64-byte stack buffer | CWE-120 | the overflow: 448 bytes past `buf`, saved RIP at +88 |
|
||
| 2 | `snprintf(line, …, "%.*s", …)` only; but attacker `%` in the echo path | CWE-134 | the leak is the real payload here; a `%n` in a *root* process would be write-what-where as root |
|
||
| 3 | children keep root while handling untrusted input | CWE-271 | the correct `drop_privs()` (setgroups→setgid→setuid, in that order, with a verify) sits in the file, commented, *deliberately uncalled* |
|
||
| 4 | `ids=`, `stack=`, `libc=`, `BUF=` disclosed to every client | CWE-200 | without these leaks the shellcode and ret2libc techniques could not compute addresses (ASLR would defeat them) |
|
||
|
||
The handler is exactly the same `buf[64]`/`read(512)` shape as the other two
|
||
labs, so the shared objdump-based discovery pipeline works unchanged.
|
||
|
||
---
|
||
|
||
## How to inspect the daemon (learning path)
|
||
|
||
```
|
||
make status # is it running? as which uid? file mode shown
|
||
make run-root # or run / run-root-ns
|
||
./foowosc -t leak # see the banner and the leaks, send nothing
|
||
./foowosc -t demo # junk overflow -> SIGSEGV, logged with RIP/rsp
|
||
./foowosc -t shellcode # the interactive root shell
|
||
make test-root # full matrix, all techniques, --must-root
|
||
```
|
||
|
||
Crash reporter: on SIGSEGV the daemon logs the faulting address, RIP and RSP.
|
||
A `ret` into non-canonical `0x4141…` faults at the `ret` itself (RIP like
|
||
`0x4028xx`, `si_addr=(nil)`) — worth knowing before you misread a log line as
|
||
a NULL dereference.
|
||
|
||
---
|
||
|
||
## Why the shellcode is 23 bytes, not 32
|
||
|
||
```
|
||
31 f6 xor esi, esi ; argv = NULL
|
||
31 d2 xor edx, edx ; envp = NULL
|
||
48 bf 2f62696e2f736800 movabs rdi, "/bin/sh\0"
|
||
57 push rdi
|
||
48 89 e7 mov rdi, rsp
|
||
6a 3b push 0x3b ; 59 = execve
|
||
58 pop rax
|
||
0f 05 syscall
|
||
```
|
||
|
||
The SUID lab needs `setreuid(0,0)` before this. This lab does not, for the
|
||
reason repeated throughout: **ruid is already 0** because root started the
|
||
process. `make verify` proves the bytes in `foowosc.c` are byte-for-byte what
|
||
`shellcode.S` assembles to.
|
||
|
||
---
|
||
|
||
## Mitigations — what `make hardened` changes
|
||
|
||
Hardened build (`-fstack-protector-strong -fPIE -pie -z noexecstack`):
|
||
|
||
| technique | vulnerable `foowosd` | hardened `foowosd_hardened` |
|
||
|-----------|----------------------|------------------------------|
|
||
| `shellcode` | root shell (executable stack) | SIGSEGV at the canary check / NX |
|
||
| `ret2win` / `ret2libc` | root shell | canary aborts `ret` — but note: a *PIE* build also makes those addresses random |
|
||
| `demo` | SIGSEGV, logged | SIGSEGV, logged |
|
||
|
||
`make test-hardened` demonstrates this live. The important observation is not
|
||
just that the mitigations killed the techniques — it is that they did **not**
|
||
make the daemon "not root". A hardened build that is still *started* as root
|
||
is still a root daemon; the mitigation only raises the bar for the attacker.
|
||
Least privilege (`drop_privs()`) and memory safety are two different bugs,
|
||
and a daemon that does not need root should not have it.
|
||
|
||
---
|
||
|
||
## Safety rails (same policy as the SUID lab)
|
||
|
||
- **Loopback only.** foowosd refuses any bind other than `127.0.0.1` /
|
||
`localhost` / `::1` unless you pass `-L`. A root daemon on a real interface
|
||
is a *remote* root service. `-L` exists solely to show the guard; do not
|
||
use it on anything that matters.
|
||
- **State is logged loudly.** Startup prints `ruid/euid` and whether this is
|
||
a root process, so you always know which exploit outcome to expect.
|
||
- **Verdicts come from exit statuses** in `make test*` (the pty harness's
|
||
return code), never from grepping its stdout — greppable output lies.
|
||
- **pty must run cooked + ECHO off** or the harness echoes its own command
|
||
line and fakes the marker. The harness turns ECHO off and keeps ECHONL on.
|
||
- **Cleanup ritual:** `make stop` after every session. If the daemon is
|
||
root-owned, `stop` tells you to run `sudo pkill -x foowosd`.
|
||
- Never run this on any host you care about. It exists to hand out `uid=0`
|
||
shells over the loopback interface.
|
||
|
||
---
|
||
|
||
## Exercises
|
||
|
||
1. Run `make run` (user daemon), then `./foowosc -t shellcode`. Why is the
|
||
shell not root? (Check `ids=` in the banner — foowosc tells you before you
|
||
even connect.)
|
||
2. `make stop && sudo make run-root && make test-root`. Explain, from the
|
||
banner line, why all four techniques now yield `uid=0(root)`.
|
||
3. In `foowosd.c`, find `drop_privs()` and read *why the order* of
|
||
`setgroups → setgid → setuid` matters. Decide where in `main()` it would
|
||
belong, and what the lab's exploit surface becomes once it is actually
|
||
called.
|
||
4. Compute `rip_off` by hand from `objdump -d foowosd`: find `buf`'s
|
||
`lea -0xNN(%rbp)` inside `vulnerable_handler`, then `NN + 8`. foowosc does
|
||
exactly this; check its math against your own.
|
||
5. `make hardened && make test-hardened`. Which technique falls to the canary
|
||
and which to NX? Why does hardening not change what `make status` reports
|
||
about the *process*?
|
||
6. Compare the two labs' shellcodes: 23 bytes here, 32 for foosd. What does
|
||
the extra 9 bytes do, and why is it only needed in the SUID case?
|
||
7. Read `become_shell()`'s comment about the single read cursor. Recreate the
|
||
failure mode mentally: two readers on one socket means the login shell eats
|
||
one byte per chunk — "uid=1000…" arrives as "id=1000…". Why can a relay
|
||
process never have this bug?
|
||
|
||
---
|
||
|
||
## Files
|
||
|
||
```
|
||
foowosd.c the vulnerable root daemon (every line commented)
|
||
foowosc.c the exploit (every line commented)
|
||
shellcode.S reference assembly for the 23-byte payload
|
||
tests/pty_wosuid_test.c the pty harness (marker + strict id-shape checks)
|
||
Makefile build / run / run-root / run-root-ns / test /
|
||
test-root / verify / hardened / clean …
|
||
```
|
||
|
||
Sibling labs: `../food.c`/`../fooc.c` (user-level baseline, port 2342) and
|
||
`../suid/` (SUID-root daemon `foosd`/`foosc`, port 2343). Ports are distinct
|
||
on purpose — you can run all three at once and cross-check their banners'
|
||
`ids=` lines. |