15 Commits

Author	SHA1	Message	Date
KaraZajac	af01d112a5	docs: netfilter_xtcompat (CVE-2021-22555) — empirical note on primitive difficulty ... Attempted the most tractable kernel primitive to gauge the frontier. Kernel confirmed vulnerable (focal GA 5.4.0-26 and a provisioned mainline 5.8.0, both pre the 5.4.0-77/5.8.0-53 fix). But Andy Nguyen's well-regarded single-file public exploit consistently fails at STAGE 1 ("could not corrupt any primary message") on both — it is tuned for Ubuntu's exact 5.8.0-48-generic slab config (freelist randomisation / memcg kmem accounting / SLUB merge), which mainline kernels don't match, and Ubuntu's EOL 5.8.0-48 HWE debs aren't readily sourceable. Recorded in docs/EXPLOITED.md: kernel primitives are config-and-version-specific exploit-dev — even a reference exploit needs its exact target kernel image + per-target tuning + a full port, a per-primitive multi-session effort. No code change; documentation of the empirical result. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 23:49:28 -04:00
KaraZajac	73c7d09445	overlayfs: direct uid=0 witness; broaden false-OK audit (all OK sites clean) ... overlayfs previously claimed EXPLOIT_OK from a getxattr proxy (the persisted security.capability xattr is the bug's signature) then exec-transferred the cap'd payload. Tightened to a DIRECT witness: the payload now takes a proof-path arg and, running as root (setuid(0) works because of the persisted cap), drops a root-owned proof + setuid bash; the module forks it, then reports OK only after stat() confirms the proof is root-owned. Re-verified on focal 5.4.0-26 (uid 1000 -> root-owned proof + -rwsr-xr-x root:root bash). Broadened the false-EXPLOIT_OK audit from exec-transfer callers to EVERY EXPLOIT_OK return site. The copy_fail_family root-pop (exploit_su.c) runs verify_plant() — confirming the shellcode actually landed in the setuid binary's page cache, reverting otherwise — before exec'ing it, so it's proxy-verified like dirtydecrypt/fragnesia, not a blind exec-transfer. Conclusion recorded in docs/EXPLOITED.md: no false-OKs remain beyond the four already fixed; every OK is backed by a real out-of-band check (root-owned artifact stat, getxattr, passwd grep, setuid(0) gate, or page-cache verify_plant). Host build + unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 23:37:57 -04:00
KaraZajac	65588599ff	dirty_cow: verify end-to-end on 4.8.0; robust su helper (dirty_pipe too) ... Verified the dirty_cow fix end-to-end on a genuinely Dirty-COW-vulnerable mainline 4.8.0 kernel (installed the kernel.ubuntu.com 4.8.0 deb on a 16.04 image + virtio-rng for entropy). A standalone built verbatim from the module's primitive + escalation raced root's password field, authenticated as root over a pty, planted a root-owned setuid bash, and left /etc/passwd byte-identical. (The full skeletonkey binary won't compile on xenial's 4.4-era uapi headers — unrelated nft_* modules use newer kernel constants — so the verbatim standalone stands in for --exploit dirty_cow there.) Robustness fix (both dirty_cow AND dirty_pipe): the su-over-pty step now POLLS for the password prompt and hard-caps at 20s. The previous fixed-delay write raced su's prompt setup and HUNG on xenial; without a cap that would block the revert and leave /etc/passwd poisoned. Now su can never hang the module, and the revert always runs. Also: netfilter_xtcompat now includes <linux/if.h> for IFNAMSIZ (ip_tables.h doesn't pull it transitively on older kernel headers, e.g. Ubuntu 16.04) — a real portability fix surfaced by building on xenial. Host build + unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 23:26:12 -04:00
KaraZajac	68dac6c063	dirty_cow: fix false-EXPLOIT_OK (same 3 bugs as dirty_pipe) + audit the corpus ... False-EXPLOIT_OK audit: the dispatcher's run_callback_isolated reports OK when the exploit execve()s (FD_CLOEXEC closes the result pipe -> parent reads EOF), so any exploit whose main path execs a not-guaranteed-root target lies. Audited every exec*-calling module (results in docs/EXPLOITED.md). dirty_cow had the identical 3-bug pattern to the pre-fix dirty_pipe: 1. raced the CALLER's UID field to "0000" then ran `su self` -> still needs the caller's password, never rooted anything; 2. execlp'd su -> dispatcher's exec-transfer path reported a FALSE EXPLOIT_OK; 3. reverted via drop_caches (needs root) -> left the running /etc/passwd corrupted when run unprivileged. Plus a latent overflow: the success-check readback[16] was too small for a payload > 16 bytes. Fix (byte-for-byte the verified dirty_pipe technique): race ROOT's password field to a known $6$ hash -> authenticate as root over a pty -> plant a root-owned proof + setuid bash -> revert by racing the original bytes back through the Dirty COW primitive (no root / no drop_caches). Success judged only by the OOB artifact; readback buffer bumped to 512. cleanup() re-reverts idempotently. The escalation half is identical to dirty_pipe (verified end-to-end); the COW primitive itself needs a pre-4.8.3 kernel to land, which no cached VM has, so on patched hosts it now fails HONESTLY with no corruption. Unit harness green. Other exec-transfer modules audited clean or already-fixed; two (overlayfs proxy, sudoedit_editor unverified reporting) noted for tightening. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 23:01:54 -04:00
KaraZajac	678a37b2f5	dirty_pipe: fix 3 bugs — working CVE-2022-0847 exploit that lands real root ... Verified out-of-band on a genuinely pre-fix mainline 5.16.0 kernel (installed from kernel.ubuntu.com onto the jammy image; every cached cloud image was pre-5.8 or backport-patched). `skeletonkey --exploit dirty_pipe` (uid 1000) -> EXPLOIT_OK + a -rwsr-xr-x root:root bash, and /etc/passwd is byte-identical afterward. Three real bugs in the shipped module: 1. Wrong escalation: it flipped the CALLER's UID field to "0000" and ran `su <self>`, which still demands the caller's password -> never rooted anything. 2. False EXPLOIT_OK: it execlp'd su, so the dispatcher's "exec transferred -> clean exit = OK" path reported success even on su's auth failure. 3. Dangerous revert: revert_passwd_page_cache() used drop_caches, which needs root -> as an unprivileged caller it left the running system's /etc/passwd page cache corrupted (broke sshd user resolution in testing). Rewrite (AabyssZG-style, self-contained + verifying): - overwrite ROOT's password field with a known $6$ crypt hash via the Dirty Pipe primitive (the longer hash clobbers into following lines, transiently); - authenticate as root over a pty with the matching password (su reads the password from the controlling tty, not stdin); - plant a root-owned proof + setuid bash; judge success ONLY by stat()'ing the root-owned artifact; - revert the page cache by writing the saved original bytes back through the Dirty Pipe primitive itself — no root, no drop_caches, nothing persists. cleanup() re-reverts idempotently. Unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 22:50:39 -04:00
KaraZajac	82ba6e0d08	sudo_samedit: working CVE-2021-3156 (Baron Samedit) exploit — lands real root ... The shipped module drove a structural sudoedit trigger with no heap-grooming offsets and honestly reported EXPLOIT_FAIL. Ported blasty's proven technique: the `sudoedit -s` set_cmnd() unescape overflow overwrites a glibc NSS service_user, so the subsequent NSS lookup dlopen's an attacker-planted libnss_X/'P0P_SH3LLZ_ .so.2' from CWD, whose constructor runs while sudo is still root. Implementation follows the corpus's runtime-compile pattern: build the NSS payload on the target (unique -DSK_PROOF/-DSK_ROOTBASH), lay out the libnss_X/ dir, exec sudoedit with the crafted argv (AAAA..\ / \ / BBBB..\) and env (null_stomp × "\\", "X/P0P_SH3LLZ_", padded LC_ALL) from that CWD, and verify root by stat()'ing the root-owned artifacts — never self-report. Grooming lengths are libc-family specific (Ubuntu 56/54/63/212, Debian 64/49/60/214); a null_stomp_len ±8 sweep (blasty brute.sh's axis) is the fallback for drift. Verified out-of-band on Ubuntu 18.04.0 / sudo 1.8.21p2 / libc-2.27, as uid 1000 (non-sudoer — the overflow precedes the sudoers/password check): `skeletonkey --exploit sudo_samedit` -> EXPLOIT_OK + a -rwsr-xr-x root:root bash, primary lengths landing first try. Gated on cc + sudoedit; cleanup() removes artifacts and the scratch build dir. Unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 22:22:11 -04:00
KaraZajac	635f7d2d24	ptrace_traceme: working CVE-2019-13272 exploit — lands real root (x86_64) ... The bundled sequence had the mechanism backwards (it PTRACE_ATTACHed the now-root parent) and never rooted anything. Replaced it with the proven Jann Horn (Project Zero #1903) / bcoles technique: - a "middle" process execs setuid pkexec (euid 0 for a window); - its child spins until it sees middle is euid 0, calls PTRACE_TRACEME (recording middle's ROOT creds as ptracer_cred — the bug), then execs pkexec itself. The traced setuid exec is NOT degraded because ptracer_cred is root, so the child becomes real root, still traced; - staged execveat() self-re-exec injects the payload as root. The staged self-re-exec needs the exploit to exist as its own binary with an argv[0] stage dispatcher, so the proven PoC is embedded verbatim (ptrace_helper_src.h — only spawn_shell() changed, to plant a root-owned proof + setuid bash instead of only an interactive shell), compiled on the target at runtime with unique -DSK_PROOF/-DSK_ROOTBASH paths, run, and verified by stat()'ing the root-owned artifacts (never self-report). Verified out-of-band on Ubuntu 18.04.0 / 4.15.0-50: `skeletonkey --exploit ptrace_traceme` as uid 1000 -> EXPLOIT_OK + a -rwsr-xr-x root:root bash. Real-world precondition, honestly reported: pkexec must authorize an auto-discovered implicit-active=yes helper, which needs an active local session (desktop) or a permissive polkit policy; over inactive ssh it returns "Not authorized" and the module reports EXPLOIT_FAIL with that diagnosis. Gated on a C compiler + pkexec; x86_64 only (register-level injection). cleanup() removes the artifacts. Unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 22:14:19 -04:00
KaraZajac	1bdbe011b0	docs: nf_tables (CVE-2024-1086) kernel confirmed vulnerable; module gap scoped ... Ran the full methodology on the flagship kernel primitive: - Built Notselwyn's public universal PoC on jammy 5.15.0-25 (below patched branch 5.15.149) and ran it: hit the deliberate post-root `kernel BUG at mm/slub.c:379` / panic — the cross-cache slab corruption fired. Kernel is genuinely exploitable. - Diffed technique: the module is an honest trigger+groom SCAFFOLD (real NFT_GOTO+NFT_DROP double-free + msg_msg cg-96 groom) whose pipapo arb-write is FALLBACK-DEPTH (exact pipapo_elem layout is a documented TODO) -> honest EXPLOIT_FAIL. Notselwyn uses a heavier universal cross-cache -> dirty-pagetable technique (~2000 LOC, multi-file, static libnftnl/libmnl, no per-kernel offsets). Completing the module's full-chain is substantial dedicated exploit-dev, not a spot-the-bug fix. The piece that was actually broken and is now fixed+pushed is the offset resolver (cd9bea6): env-provided offsets were wiped under kptr_restrict, which blocked the entire --full-chain path. Recorded in 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 21:55:39 -04:00
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