7 Commits

Author	SHA1	Message	Date
KaraZajac	6960d2076d	docs: record sudo_host (CVE-2025-32462) confirmed landing root ... sudo_host works as shipped — no code change. VM-verified on Ubuntu 22.04.0 / sudo 1.9.9-1ubuntu2: with a host-restricted sudoers rule (scoped to a host that is neither the current hostname nor ALL) and a resolvable host name, `sudo -h <host> <cmd>` runs as uid 0 (the -h/--host authorization-logic flaw). Module confirmed EXPLOIT_OK with a real uid=0 witness and popped a root shell. The only preconditions are environmental (the host-restricted rule, common with fleet-wide/LDAP/SSSD sudoers, supplied via SKELETONKEY_SUDO_HOST) — not a bug. VERIFICATIONS.jsonl + EXPLOITED.md updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 21:34:24 -04:00
KaraZajac	70972e0c9d	sudoedit_editor: fix CVE-2023-22809 exploit to actually land root ... The module built the right EDITOR="helper -- /etc/passwd" injection but failed two ways, both now fixed (VM-verified root on Ubuntu 22.04.0 / sudo 1.9.9-1ubuntu2): 1. Writable-CWD guard: sudoedit refuses to edit any file whose parent dir is user-writable. The injected "--" is resolved relative to CWD, so running from home/tmp made sudoedit abort "--: editing files in a writable directory" before the editor ran. Fix: chdir("/") in the sudoedit child. 2. Wrong tmp copy: sudoedit hands the editor one tmp copy per file, named <basename>.XXXXXX. The helper wrote argv[argc-1] — the sudoers-authorized COVER file (e.g. motd), not the target. Fix: the helper now matches the target's basename prefix (passed via SKEL_TARGET) to pick the right copy. Result: /etc/passwd gains a skel::0:0 row; `su skel` -> uid=0(root). docs/EXPLOITED.md + VERIFICATIONS.jsonl updated. Unit harness green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 21:32:44 -04:00
KaraZajac	6edf78f765	overlayfs_setuid: working CVE-2023-0386 exploit (libfuse) — lands real root ... The shipped module used a bogus chown-the-merged-view technique that never worked. Rewrote it as a faithful port of the public PoC (xkaneiki): a libfuse filesystem exports a setuid-root /file (st_uid=0, mode 04777), mounted in the init ns via the setuid fusermount helper; then unshare(USER|NS) + overlay with that FUSE mount as lowerdir; open(merged/file, O_WRONLY) triggers copy-up which materialises upper/file as a genuine setuid-root binary; the unprivileged parent execs it for real root. VM-verified landing real root on Ubuntu 22.04.0 / 5.15.0-25 (uid=0 witnessed out-of-band: /tmp/skeletonkey-ovlsu-pwned shows uid=0(root), and the dropped setuid /tmp/.suid_bash runs with euid=0). Four things were each required and took isolation to find: 1. Overlay refuses a userns-mounted FUSE lowerdir (ENOSYS) -> FUSE must be mounted in the init ns via fusermount (libfuse). A raw /dev/fuse server was tried and abandoned (fragile; destabilised the kernel on malformed INIT). 2. fuse2 low-level API (fuse_mount/fuse_new/fuse_loop_mt, empty args); fuse_main advertises copy_file_range caps that ENOSYS at copy-up with no fallback. 3. read_buf callback (copy-up splice read path). 4. ioctl callback (copy-up's FS_IOC_GETFLAGS) — the last missing piece. libfuse is linked conditionally via pkg-config (fuse/fuse3), matching the pack2theroot+libglib precedent; without it the module stubs to PRECOND_FAIL. Makefile detects it and adds $(OSU_LIBS) to the link. Module header + opsec notes rewritten to the real technique; docs/EXPLOITED.md updated. 148-test unit harness green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 21:26:13 -04:00
KaraZajac	3edad37184	docs: overlayfs_setuid debug outcome — kernel confirmed vulnerable, raw /dev/fuse fragile, use libfuse ... Confirmed CVE-2023-0386 vulnerable on jammy 5.15.0-25.25 empirically (upstream xkaneiki libfuse PoC pops root). Isolated the raw /dev/fuse port's failures: overlay refuses a userns-mounted FUSE lowerdir (ENOSYS) so FUSE must be mounted in the init ns via the setuid fusermount3 helper; got the fd-passing handshake + mount working, but the server EINVALs on read after FUSE_INIT (non-blocking fd, needs poll) and the flaky raw server repeatedly wedged/rebooted the VM. Raw protocol reimplementation is fragile and can destabilise the target -> use libfuse (proven, matches pack2theroot conditional-lib precedent). Ledger updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 20:57:27 -04:00
KaraZajac	58b44ebc43	docs: record overlayfs_setuid (FUSE port needed) + sudoedit_editor findings ... overlayfs_setuid (CVE-2023-0386) investigated on Ubuntu 22.04.0 / 5.15.0-25 (genuinely vulnerable): the non-FUSE chown copy-up yields upper/file owned by uid 1000 (no escalation), and overlay refuses a userns-mounted FUSE lowerdir with ENOSYS (plain overlay-in-userns works). A working exploit must mount FUSE in the init ns via the setuid fusermount helper (fd-passing protocol) then overlay in the userns — a substantial dedicated port. A raw /dev/fuse server was written and reverted after hitting the ENOSYS wall. sudoedit_editor (CVE-2023-22809) on sudo 1.9.9 returns EXPLOIT_FAIL — the SUDO_EDITOR/-- arg injection reaches sudoedit's writable-dir guard; needs target-file tuning and module debugging. Tractable next. Ledger + VERIFICATIONS.jsonl updated. No code change (overlayfs_setuid reverted to baseline; not committing a second non-working variant). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 20:34:58 -04:00
KaraZajac	e01aa99ec6	af_packet2: fix uid_map (read uid/gid before unshare) — same bug as cgroup ... af_packet2 read getuid()/getgid() AFTER unshare(CLONE_NEWUSER), so it wrote "0 65534 1" to uid_map/gid_map (65534 = nobody, the initial unmapped id) and the write was rejected EPERM — the userns-root mapping silently failed and the CAP_NET_RAW primitive could not fire. Capture the outer uid/gid before unshare. Audited every userns module for the pattern; only cgroup_release_agent (fixed in 8c45b2b) and af_packet2 had it. Updated docs/EXPLOITED.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 20:18:03 -04:00
KaraZajac	59cc2be065	ptrace_traceme: stop the false EXPLOIT_OK; add exploit-verification ledger ... ptrace_traceme reported EXPLOIT_OK while obtaining no root on a genuinely vulnerable host (Ubuntu 18.04.2 / 4.15.0-50). The bundled ptrace sequence is a non-working placeholder — it PTRACE_ATTACHes to the tracer, which by then has reparented to init, so the attach fails EPERM; the parent then execve'd the setuid trigger and the dispatcher's exec-transfer path reported a false OK. Now the parent fires the trigger in a grandchild, stays alive, and verifies euid==0 before claiming success — otherwise honest EXPLOIT_FAIL with a pointer to the real CVE-2019-13272 technique (Jann Horn / bcoles) that still needs porting. Adds docs/EXPLOITED.md: the exploit-verification ledger (root witnessed OUT OF BAND, not from the module's self-report). Confirmed landing root: refluxfs, overlayfs, pwnkit (after its gconv fix), sudo_runas_neg1. Needs PoC ports: ptrace_traceme, overlayfs_setuid (CVE-2023-0386 FUSE copy-up), sudo_samedit (heap), cgroup_release_agent. ~30 modules still exploit-untested. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 19:59:48 -04:00