32 Commits

Author	SHA1	Message	Date
leviathan	fa0228df9b	release v0.9.3: CVE metadata refresh (KEV 10→12) + dirtydecrypt bug fix ... CVE metadata refresh: - Added 8 entries to core/cve_metadata.c for the v0.8.0 + v0.9.0 module CVEs. Two are CISA-KEV-listed: - CVE-2018-14634 mutagen_astronomy (2026-01-26, CWE-190) - CVE-2025-32463 sudo_chwoot (2025-09-29, CWE-829) - Populated via direct curl when refresh-cve-metadata.py's Python urlopen hung on CISA's HTTP/2 endpoint for ~55 min — same data, different transport. dirtydecrypt module bug fix: - dd_detect() was wrongly gating 'predates the bug' on kernel < 7.0 - Per NVD CVE-2026-31635: bug entered at 6.16.1 stable; vulnerable through 6.18.22 / 6.19.12 / 7.0-rc7; fixed at 6.18.23 / 6.19.13 / 7.0 - Fix: predates-gate now uses 6.16.1; patched_branches[] adds {6,18,23} - Re-verified: dirtydecrypt now correctly returns VULNERABLE on mainline 6.19.7 instead of OK. Previously a false negative on real vulnerable kernels. Footer goes from '10 in CISA KEV' to '12 in CISA KEV'. Verified count stays at 28 but dirtydecrypt's record is now a TRUE VULNERABLE match (was OK match).	2026-05-24 01:17:58 -04:00
leviathan	d52fcd5512	docs: sweep stale counts to match v0.9.2 binary state ... Audit found several user-facing surfaces still carrying old numbers from earlier releases. Brought everything in line with the binary's authoritative footer ('39 modules · 10 KEV · 28 verified · 7 any'). README.md: - Status section: v0.9.0 → v0.9.2 framing; describe the 22 → 28 verification arc (v0.9.1 + v0.9.2) - '119 detection rules' → 151 (current bundled count) - '10 of 26 KEV-listed' → '10 of 34' - 'Not yet verified (4 of 26 CVEs)' → '(6 of 34 CVEs)' with the new honest list (vmwgfx, dirty_cow, mutagen_astronomy, pintheft, vsock_uaf, fragnesia) and the reason each is blocked - Example --auto output: 31 → 39 modules docs/index.html: - '22 of 26 CVEs confirmed' → '28 of 34', mainline kernel list expanded (5.4.0-26 / 5.15.5 / 6.1.10 / 6.19.7) - Corpus section '26 CVEs across 10 years' → '34 CVEs' - '26 CVEs, 10-year span' (author list intro) → '34 CVEs' - Footer feature list '22 of 26' → '28 of 34' - KEV stat chip 11 → 10 (matches binary; the anticipated 11th from metadata refresh hasn't been added yet) - '119 detection rules' → '151' (two occurrences) docs/og.svg + og.png: - KEV chip 11 → 10 (matches binary) CVES.md: - '31 modules' → '39 modules covering 34 CVEs' - Rewrote the unverified-rows note to match the actual 6-module list No content changes to RELEASE_NOTES.md or ROADMAP.md — those entries correctly describe state at the time they were written.	2026-05-24 00:09:21 -04:00
leviathan	66cca39a55	release v0.9.2: dirtydecrypt verified on mainline 6.19.7 (22 → 28) ... Verifies CVE-2026-31635 dirtydecrypt's OK path on a kernel that predates the bug: 'kernel predates the rxgk RESPONSE-handling code added in 7.0' — match. Confirms detect() doesn't false-positive on older 6.x kernels. Attempted fragnesia (CVE-2026-46300) but mainline 7.0.5 .debs depend on libssl3t64 / libelf1t64 (t64-transition libs from Ubuntu 24.04+ / Debian 13+). No Parallels-supported Vagrant box ships those yet — dpkg --force-depends leaves the kernel package in iHR state with no /boot/vmlinuz. Marked manual: true with rationale. Verifier infrastructure: pin-mainline now uses dpkg --force-depends as a fallback so partial-install state can at least be inspected.	2026-05-24 00:03:35 -04:00
leviathan	8ac041a295	release v0.9.1: VM verification sweep 22 → 27 ... Five more CVEs empirically confirmed end-to-end against real Linux VMs: - CVE-2019-14287 sudo_runas_neg1 (Ubuntu 18.04 + sudoers grant) - CVE-2020-29661 tioscpgrp (Ubuntu 20.04 pinned to 5.4.0-26) - CVE-2024-26581 nft_pipapo (Ubuntu 22.04 + mainline 5.15.5) - CVE-2025-32463 sudo_chwoot (Ubuntu 22.04 + sudo 1.9.16p1 from source) - CVE-2025-6019 udisks_libblockdev (Debian 12 + udisks2 + polkit rule) Required real plumbing work: - Per-module provisioner hook (tools/verify-vm/provisioners/<module>.sh) - Two-phase provision in verify.sh (prep → reboot if needed → verify) fixes silent-fail where new kernel installed but VM never rebooted - GRUB_DEFAULT pinning in both pin-kernel and pin-mainline blocks (kernel downgrades like 5.4.0-169 → 5.4.0-26 now actually boot the target) - Old-mainline URL fallback in pin-mainline (≤ 4.15 debs at /v$KVER/ not /amd64/) mutagen_astronomy marked manual: true — mainline 4.14.70 kernel-panics on Ubuntu 18.04's rootfs ('Failed to execute /init (error -8)' — kernel config mismatch). Genuinely needs a CentOS 6 / Debian 7 image.	2026-05-23 23:35:02 -04:00
leviathan	d84b3b0033	release v0.9.0: 5 gap-fillers — every year 2016 → 2026 now covered ... Five new modules close the 2018 gap entirely and thicken 2019 / 2020 / 2024. All five carry the full 4-format detection-rule corpus + opsec_notes + arch_support + register helpers. CVE-2018-14634 — mutagen_astronomy (Qualys, closes 2018) create_elf_tables() int wrap → SUID-execve stack corruption. CISA KEV-listed Jan 2026 despite the bug's age; legacy RHEL 7 / CentOS 7 / Debian 8 fleets still affected. 🟡 PRIMITIVE. arch_support: x86_64+unverified-arm64. CVE-2019-14287 — sudo_runas_neg1 (Joe Vennix) sudo -u#-1 → uid_t underflow → root despite (ALL,!root) blacklist. Pure userspace logic bug; the famous Apple Information Security finding. detect() looks for a (ALL,!root) grant in sudo -ln output; PRECOND_FAIL when no such grant exists for the invoking user. arch_support: any (4 -> 5 userspace 'any' modules). CVE-2020-29661 — tioscpgrp (Jann Horn / Project Zero) TTY TIOCSPGRP ioctl race on PTY pairs → struct pid UAF in kmalloc-256. Affects everything through Linux 5.9.13. 🟡 PRIMITIVE (race-driver + msg_msg groom). Public PoCs from grsecurity / spender + Maxime Peterlin. CVE-2024-50264 — vsock_uaf (a13xp0p0v / Pwnie Award 2025 winner) AF_VSOCK connect-race UAF in kmalloc-96. Pwn2Own 2024 + Pwnie 2025 winner. Reachable as plain unprivileged user (no userns required — unusual). Two public exploit paths: @v4bel+@qwerty kernelCTF (BPF JIT spray + SLUBStick) and Alexander Popov / PT SWARM (msg_msg). 🟡 PRIMITIVE. CVE-2024-26581 — nft_pipapo (Notselwyn II, 'Flipping Pages') nft_set_pipapo destroy-race UAF. Sibling to nf_tables (CVE-2024-1086) from the same Notselwyn paper. Distinct bug in the pipapo set substrate. Same family signature. 🟡 PRIMITIVE. Plumbing changes: core/registry.h + registry_all.c — 5 new register declarations + calls. Makefile — 5 new MUT/SRN/TIO/VSK/PIP module groups in MODULE_OBJS. tests/test_detect.c — 7 new test rows covering the new modules (above-fix OK, predates-the-bug OK, sudo-no-grant PRECOND_FAIL). tools/verify-vm/targets.yaml — verifier entries for all 5 with honest 'expect_detect' values based on what Vagrant boxes can realistically reach (mutagen_astronomy gets OK on stock 18.04 since 4.15.0-213 is post-fix; sudo_runas_neg1 gets PRECOND_FAIL because no (ALL,!root) grant on default vagrant user; tioscpgrp + nft_pipapo VULNERABLE with kernel pins; vsock_uaf flagged manual because vsock module rarely available on CI runners). tools/refresh-cve-metadata.py — added curl fallback for the CISA KEV CSV fetch (urlopen times out intermittently against CISA's HTTP/2 endpoint). Corpus growth across v0.8.0 + v0.9.0: v0.7.1 v0.8.0 v0.9.0 Modules 31 34 39 Distinct CVEs 26 29 34 KEV-listed 10 10 11 (mutagen_astronomy) arch 'any' 4 6 7 (sudo_runas_neg1) Years 2016-2026: 10/11 10/11 **11/11** Year-by-year coverage: 2016: 1 2017: 1 2018: 1 2019: 2 2020: 2 2021: 5 2022: 5 2023: 8 2024: 3 2025: 2 2026: 4 CVE-2018 gap → CLOSED. Every year from 2016 through 2026 now has at least one module. Surfaces updated: - README.md: badge → 22 VM-verified / 34, Status section refreshed - docs/index.html: hero eyebrow + footer → v0.9.0, hero tagline 'every year 2016 → 2026', stats chips → 39 / 22 / 11 / 151 - docs/RELEASE_NOTES.md: v0.9.0 entry added on top with year coverage matrix + per-module breakdown; v0.8.0 + v0.7.1 entries preserved below - docs/og.svg + og.png: regenerated with new numbers + 'Every year 2016 → 2026' tagline CVE metadata refresh (tools/refresh-cve-metadata.py) deferred to follow-up — CISA KEV CSV + NVD CVE API were timing out during the v0.9.0 push window. The 5 new CVEs will return NULL from cve_metadata_lookup() until the refresh runs (—module-info simply skips the WEAKNESS/THREAT INTEL header for them; no functional impact). Re-run 'tools/refresh-cve-metadata.py' when network cooperates. Tests: macOS local 33/33 kernel_range pass; detect-test stubs (88 total) build clean; ASan/UBSan + clang-tidy CI jobs still green from the v0.7.x setup.	2026-05-23 22:15:44 -04:00
leviathan	4af82b82d9	docs: post-v0.7.1 surface sync (README + site + ROADMAP) ... Three stale surfaces refreshed after the v0.7.1 cut + arm64 release: README.md — Status section was 'v0.6.0 cut 2026-05-23'; updated to v0.7.1 with the new prebuilt-binary inventory (4 artifacts: x86_64 + arm64, each dynamic + static-musl) and the CI hardening additions (ASan/UBSan + clang-tidy). docs/index.html — hero eyebrow chip and footer meta both showed v0.6.0; both bumped to v0.7.1. ROADMAP.md — entire v0.7.x phase added as 'Phase 9 — Empirical verification + operator briefing (DONE 2026-05-23, v0.7.1)'. Captures everything since Phase 7+/8 (which were the v0.5–v0.6 era): the VM verifier, mainline kernel fetch, 22 of 26 CVEs verified, --explain mode, OPSEC notes, CVE metadata pipeline (CISA KEV + NVD CWE), 119 detection rules, 88-test harness, arm64-static binary, arch_support field, marketing site. Plus an explicit 'open follow-ups' list (arm64 verification sweep, SIEM query templates, install.sh smoke test, PackageKit provisioner, custom <=4.4 kernel image for dirty_cow, 9 deferred drift findings) and the 'wait-for-upstream blockers' list (vmwgfx, dirtydecrypt, fragnesia).	2026-05-23 21:27:23 -04:00
leviathan	5d48a7b0b5	release v0.7.1: arm64-static binary + per-module arch_support ... Two additions on top of v0.7.0: 1. skeletonkey-arm64-static is now published alongside the existing x86_64-static binary. Built native-arm64 in Alpine via GitHub's ubuntu-24.04-arm runner pool (free for public repos as of 2024). install.sh auto-picks it based on 'uname -m'; SKELETONKEY_DYNAMIC=1 fetches the dynamic build instead. Works on Raspberry Pi 4+, Apple Silicon Linux VMs, AWS Graviton, Oracle Ampere, Hetzner ARM, etc. .github/workflows/release.yml refactor: the previous single build-static-x86_64 job becomes a build-static matrix with two entries (x86_64-static on ubuntu-latest, arm64-static on ubuntu-24.04-arm). Both share the same Alpine container + build recipe. 2. .arch_support field on struct skeletonkey_module — honest per-module labeling of which architectures the exploit() body has been verified on. Three categories: 'any' (4 modules): pwnkit, sudo_samedit, sudoedit_editor, pack2theroot. Purely userspace; arch-independent. 'x86_64' (1 module): entrybleed. KPTI prefetchnta side-channel; x86-only by physics. Already source-gated (returns PRECOND_FAIL on non-x86_64). 'x86_64+unverified-arm64' (26 modules): kernel exploitation code. The bug class is generic but the exploit primitives (msg_msg sprays, finisher chain, struct offsets) haven't been confirmed on arm64. detect() still works (just reads ctx->host); only the --exploit path is in question. --list now has an ARCH column (any / x64 / x64?) and the footer prints 'N arch-independent (any)'. --module-info prints 'arch support: <value>'. --scan --json adds 'arch_support' to each module record. This is the honest 'arm64 works for detection on every module + exploitation on 4 of them today; the rest await empirical arm64 sweep' framing — not pretending the kernel exploits already work there, but not blocking the arm64 binary on that either. arm64 users get the full triage workflow + a handful of userspace exploits out of the box, plus a clear roadmap for the rest. Future work to promote modules from 'x86_64+unverified-arm64' to 'any': add an arm64 Vagrant box (generic/debian12-arm64 etc.) to tools/verify-vm/ and run a verification sweep on Apple Silicon / ARM Linux hardware.	2026-05-23 21:10:54 -04:00
leviathan	264759832a	release v0.7.0: 22-of-26 VM-verified + --explain + OPSEC + KEV metadata ... Bumps SKELETONKEY_VERSION to 0.7.0 and adds docs/RELEASE_NOTES.md with the full v0.7.0 changelog. release.yml updated to use the hand-written notes file as the GitHub Release body (falls back to the auto-generated stub when docs/RELEASE_NOTES.md isn't present, so older tags still publish cleanly). Headline: empirical VM verification across 22 of 26 CVEs, plus the --explain operator briefing mode, OPSEC notes per module, CISA KEV + NVD CWE + MITRE ATT&CK metadata pipeline, 119 detection rules across all 4 SIEM formats, kernel.ubuntu.com mainline kernel fetch path, and the new marketing-grade landing page. Full breakdown in docs/RELEASE_NOTES.md. Tag v0.7.0 next; release workflow auto-builds + publishes the 3 binaries (x86_64 dynamic, x86_64 static-musl via Alpine, arm64 dynamic) with checksums.	2026-05-23 20:44:45 -04:00
leviathan	6e0f811a2c	README + site + binary: surface 22-of-26 VM-verified count ... Updates the visible 'how trustworthy is this' signal across all three touchpoints after the verifier sweep landed 22 modules confirmed in real Linux VMs: README.md - Badge: '28 verified + 3 ported' → '22 VM-verified / 26'. - Headline tagline: emphasizes the 22-of-26 empirical confirmation. - 'Corpus at a glance' restructured: tier counts unchanged, but the stale '3 ported-but-unverified' subsection is replaced by a new 'Empirical verification' table breaking the 22 records down by distro/kernel. - 'Status' section refreshed for v0.6.0 reality: 88 tests + 22 verifications + mainline kernel fetch + --explain + KEV/CWE/ATT&CK metadata + 119 detection rules. The four still-unverified entries (vmwgfx, dirty_cow, dirtydecrypt, fragnesia) are listed with their blocking reasons. docs/index.html - Hero stats row gets a new '22 ✓ VM-verified' chip (emerald-styled via new .stat-vfy CSS class), keeping modules/KEV/rules siblings. - Hero tagline calls out '22 of 26 CVEs empirically verified'. - Meta description + og:description updated. - Bento card 'Verifier ready' rewritten as '22 modules empirically verified' with concrete distro/kernel breakdown; styled with new .bento-vfy class for emerald accent (matches the stat chip). - Timeline 'shipped' column adds the verifier wins; 'in flight' swapped to current open items (drift fixes, packagekit provisioner, custom <=4.4 box for dirty_cow). docs/og.svg + docs/og.png - 4-chip stats row instead of 3: 31 modules · 22 ✓ VM-verified · 10 ★ in CISA KEV · 119 detection rules. Tagline now '22 of 26 CVEs verified in real Linux VMs.' Re-rendered to PNG via rsvg-convert. skeletonkey.c (binary) - --list footer now prints '31 modules registered · 10 in CISA KEV (★) · 22 empirically verified in real VMs (✓)'. Counts computed from the registry + cve_metadata + verifications tables at runtime (so it stays accurate as more verifications land — the JSONL refresh propagates automatically). No code logic changed; only surfacing.	2026-05-23 18:03:38 -04:00
leviathan	312e7d89b5	verify-vm: kernel.ubuntu.com mainline integration — 22 modules verified ... Unblocks the 4 previously-PIN_FAIL modules by adding a fallback path to kernel.ubuntu.com/mainline/ for any kernel no longer in apt. Adds 4 more matches to the verified_on table for a total of 22 modules confirmed against real Linux VMs: af_unix_gc ubuntu2204 + mainline 5.15.5 match nf_tables ubuntu2204 + mainline 5.15.5 match nft_set_uaf ubuntu2204 + mainline 5.15.5 match stackrot ubuntu2204 + mainline 6.1.10 match Mechanism: tools/verify-vm/Vagrantfile — new 'pin-mainline-<X.Y.Z>' shell provisioner. Fetches the directory index at https://kernel.ubuntu.com/mainline/v<X.Y.Z>/amd64/, parses out the 4 canonical .deb filenames (linux-headers _all, linux-headers -generic _amd64, linux-image-unsigned -generic _amd64, linux-modules -generic _amd64; skips lowlatency), downloads them, runs 'dpkg -i' + 'update-grub', and prints a reboot hint. Mainline package version like '5.15.5-051505' sorts ABOVE Ubuntu's stock '5.15.0-91' in debian-version-compare (numeric 51505 > 91), so update-grub puts it at the top of the boot menu and the next 'vagrant reload' lands on it automatically. uname then reports '5.15.5-051505-generic' which our parser sees as 5.15.5 → in our kernel_range table's vulnerable window → empirical VULNERABLE. tools/verify-vm/verify.sh — new SKK_VM_MAINLINE_VERSION env passed to the Vagrantfile. Reload trigger now also fires when uname doesn't match the mainline target. tools/verify-vm/targets.yaml — new 'mainline_version' field on the 4 PIN_FAIL targets. kernel_pkg is left empty; mainline_version drives the fetch. Picked 5.15.5 (Nov 2021) for the 5.15-line CVEs and 6.1.10 (Feb 2023) for stackrot — both below every relevant backport. Final sweep status (22 of 26 CVEs): ✓ MATCHES (22): pwnkit, cgroup_release_agent, netfilter_xtcompat, fuse_legacy, nft_fwd_dup, entrybleed, overlayfs, overlayfs_setuid, sudoedit_editor, ptrace_traceme, sudo_samedit, af_packet, pack2theroot, cls_route4, nft_payload, af_packet2, sequoia, dirty_pipe, nf_tables, af_unix_gc, nft_set_uaf, stackrot 🚫 NOT VERIFIED (4 — flagged in targets.yaml with rationale): vmwgfx — VMware-guest only; no public Vagrant box covers it dirtydecrypt — needs Linux 7.0; not shipping as any distro kernel fragnesia — needs Linux 7.0; same dirty_cow — needs ≤ 4.4 kernel; older than every supported Vagrant box (would need a custom image) copy_fail_family entries verified indirectly via the shared infrastructure tests in the kernel_range unit-test harness. The 22 records are baked into core/verifications.c and surface in --list (VFY ✓ column), --module-info (--- verified on --- section), --explain (VERIFIED ON section), and JSON output (verified_on array). 22/26 CVEs is the new trust signal; with the mainline fetch path production-ready, additional pin targets can be added to targets.yaml without code changes.	2026-05-23 17:35:13 -04:00
leviathan	2c131df1bf	verify-vm sweep complete: 18 modules confirmed across 5 Linux distros ... Full sweep results: MATCHES (18 — empirically confirmed in real Linux VMs): pwnkit ubuntu2004 5.4.0-169 VULNERABLE cgroup_release_agent debian11 5.10.0-27 VULNERABLE netfilter_xtcompat debian11 5.10.0-27 VULNERABLE fuse_legacy debian11 5.10.0-27 VULNERABLE nft_fwd_dup debian11 5.10.0-27 VULNERABLE entrybleed ubuntu2204 5.15.0-91 VULNERABLE overlayfs ubuntu2004 5.4.0-169 VULNERABLE overlayfs_setuid ubuntu2204 5.15.0-91 VULNERABLE sudoedit_editor ubuntu2204 5.15.0-91 PRECOND_FAIL (no sudoers grant) ptrace_traceme ubuntu1804 4.15.0-213 VULNERABLE sudo_samedit ubuntu1804 4.15.0-213 VULNERABLE af_packet ubuntu1804 4.15.0-213 OK (4.15 is post-fix) pack2theroot debian12 6.1.0-17 PRECOND_FAIL (no PackageKit installed) cls_route4 ubuntu2004 5.15.0-43 VULNERABLE nft_payload ubuntu2004 5.15.0-43 VULNERABLE af_packet2 ubuntu2004 5.4.0-26 VULNERABLE sequoia ubuntu2004 5.4.0-26 VULNERABLE dirty_pipe ubuntu2204 5.15.0-91 OK (silently backported) PIN_FAIL (4 — targeted HWE kernels no longer in apt; needs kernel.ubuntu.com mainline integration, deferred): nf_tables wanted ubuntu2204 + 5.15.0-43-generic af_unix_gc wanted ubuntu2204 + 5.15.0-43-generic stackrot wanted ubuntu2204 + 6.1.0-13-generic nft_set_uaf wanted ubuntu2204 + 5.19.0-32-generic MANUAL / SPECIAL TARGETS (5 — flagged in targets.yaml): vmwgfx — VMware-guest only; no Vagrant box covers it dirtydecrypt — needs Linux 7.0 (not shipping yet) fragnesia — needs Linux 7.0 (not shipping yet) dirty_cow — needs <= 4.4 (older than every supported Vagrant box) copy_fail family — multi-module family verification deferred Several findings the active-probe path surfaced vs version-only checks: - dirty_pipe (ubuntu2204): version-only check would say VULNERABLE (kernel 5.15.0 < 5.15.25 backport in our table), but Ubuntu has silently backported the fix into the -91 patch level. --active probe correctly identified the primitive as blocked → OK. - af_packet (ubuntu1804): the bug was fixed in 4.10.6 mainline + 4.9.18 backport. Ubuntu 18.04's stock 4.15.0 is post-fix — detect() correctly returns OK. The targets.yaml entry was originally wrong; fixed now. - sudoedit_editor: version-wise the host is vulnerable (sudo 1.9.9), but the bug requires an actual sudoedit grant in /etc/sudoers — and the default Vagrant user has none. detect() correctly returns PRECOND_FAIL ('vuln version present, no grant to abuse'). Same as one of our unit tests. - pack2theroot: needs an active PackageKit daemon on the system bus. Debian 12's generic cloud image is server-oriented and omits PackageKit. detect() correctly returns PRECOND_FAIL. Provisioning PackageKit in a follow-up Vagrant step would unblock the VULNERABLE path verification. Plumbing fixes that landed in the sweep: - core/nft_compat.h — NFTA_CHAIN_FLAGS (kernel 5.7) + NFTA_CHAIN_ID (5.13). Without these, nft_fwd_dup fails to compile against Ubuntu 18.04's 4.15-era nf_tables uapi, which blocked the entire skeletonkey binary from building on that box and prevented verification of ptrace_traceme / sudo_samedit / af_packet. - tools/verify-vm/Vagrantfile — 'privileged: false' on the build-and-verify provisioner. Vagrant's default runs as root; pack2theroot's detect() short-circuits with 'already root — nothing to do' when running as uid 0, which would invalidate every euid-aware module's verification. - tools/verify-vm/targets.yaml — corrected expectations for af_packet (stock 18.04 4.15 is post-fix), pack2theroot (no PackageKit on server cloud image), sudoedit_editor (no sudoers grant), and dirty_pipe (silent Ubuntu backport). - tools/refresh-verifications.py — dedup key changed from (module, vm_box, host_kernel, expect_detect) to (module, vm_box, host_kernel). When an expectation is corrected mid-sweep, the new record cleanly supersedes the old one instead of accumulating. The verifier loop is now production-ready and the trust signal in --list / --module-info / --explain reflects 18 modules confirmed against real Linux. Next-step bucket: - kernel.ubuntu.com mainline integration → unblock 4 PIN_FAIL pins. - Optional PackageKit provisioner on debian12 → unblock pack2theroot VULNERABLE path.	2026-05-23 16:29:50 -04:00
leviathan	48d5f15828	verify-vm sweep: 13 modules confirmed end-to-end + Vagrant fixes ... Sweep results across 3 phases: Phase 1 (no-pin, cached boxes) — 4/5 match: entrybleed ubuntu2204 5.15.0-91-generic match overlayfs ubuntu2004 5.4.0-169-generic match overlayfs_setuid ubuntu2204 5.15.0-91-generic match nft_fwd_dup debian11 5.10.0-27-amd64 match sudoedit_editor ubuntu2204 MISMATCH (no sudoers grant — expected-fix below) Phase 2 (new boxes ubuntu1804 + debian12) — 0/4 match: ptrace_traceme \ sudo_samedit \ all FAILED to build: nft_fwd_dup needs af_packet / NFTA_CHAIN_FLAGS (kernel 5.7), not in 4.15 uapi pack2theroot / pack2theroot also hit 'already root' early-exit (running as root via vagrant provision's default privileged shell) Phase 3 (kernel-pinned) — 4/8 match: cls_route4 ubuntu2004 + 5.15.0-43 HWE match nft_payload ubuntu2004 + 5.15.0-43 HWE match af_packet2 ubuntu2004 + 5.4.0-26 (still in apt!) match sequoia ubuntu2004 + 5.4.0-26 match nf_tables, af_unix_gc, stackrot, nft_set_uaf — PIN_FAIL (target kernels not in apt; need kernel.ubuntu.com mainline integration — deferred) Total: 13 modules verified end-to-end against real Linux VMs, covering kernels 5.4 / 5.10 / 5.15 / 5.4-HWE / 5.15-HWE across Ubuntu 18.04/20.04/22.04 + Debian 11/12. Three fixes for the next retry pass: 1. core/nft_compat.h — added NFTA_CHAIN_FLAGS (kernel 5.7) and NFTA_CHAIN_ID (kernel 5.13). Without these, nft_fwd_dup fails to compile on Ubuntu 18.04's 4.15-era nf_tables uapi, which blocks the entire skeletonkey build (and thus blocks ALL verifications on that box). 2. tools/verify-vm/Vagrantfile — build-and-verify provisioner now runs unprivileged (privileged: false) so detect()s that gate on 'are you already root?' don't short-circuit. pack2theroot's 'already root — nothing to do' was the motivating case; logging 'id' upfront will make this easier to diagnose next time. 3. tools/verify-vm/targets.yaml — sudoedit_editor's expectation updated from VULNERABLE to PRECOND_FAIL. Ubuntu 22.04 ships sudo 1.9.9 (vulnerable version), but the default 'vagrant' user has no sudoedit grant in /etc/sudoers, so detect() correctly short-circuits ('vuln version present, no grant to abuse'). Provisioning a grant before verifying would re-open the VULNERABLE path; deferred. Next: re-sweep the 5 failed modules (ptrace_traceme, sudo_samedit, af_packet, pack2theroot, sudoedit_editor) and pull the 4 PIN_FAIL ones into a 'requires mainline kernel' bucket in targets.yaml.	2026-05-23 16:22:10 -04:00
leviathan	67d091dd37	verified_on table — 5 modules empirically confirmed in real VMs ... Closes the loop opened by tools/verify-vm/: every JSON verification record now persists into docs/VERIFICATIONS.jsonl, gets folded into the embedded core/verifications.c lookup table, and surfaces in --list / --module-info / --explain / --scan --json. New: docs/VERIFICATIONS.jsonl Append-only store. One JSON record per verify.sh run. Records carry module, ISO timestamp, host_kernel, host_distro, vm_box, expected vs actual verdict, and match status. 6 lines today (5 unique after dedup; the extra is dirty_pipe's pre-correction MISMATCH that surfaced the silent-backport finding — kept in the JSONL for history, deduped out of the C table). New: tools/refresh-verifications.py Parses VERIFICATIONS.jsonl, dedupes to latest per (module, vm_box, host_kernel), generates core/verifications.c with a static array + lookup functions: verifications_for_module(name, &count_out) verifications_module_has_match(name) --check mode for CI drift detection. New: core/verifications.{h,c} Embedded record table. Lookup is O(corpus); we have <50 records. skeletonkey.c surfacing: - --list: new 'VFY' column shows ✓ for modules with >=1 'match' record. Five modules show ✓ today (pwnkit, cgroup_release_agent, netfilter_xtcompat, fuse_legacy, dirty_pipe). - --module-info: new '--- verified on ---' section enumerates every record with date / distro / kernel / vm_box / status. Modules with zero records get a 'run tools/verify-vm/verify.sh <name>' hint. - --explain: new 'VERIFIED ON' section in the operator briefing. - --scan --json / --module-info --json: 'verified_on' array of record objects per module. Verification records baked in: pwnkit Ubuntu 20.04.6 LTS 5.4.0-169 match (polkit 0.105) cgroup_release_agent Debian 11 (bullseye) 5.10.0-27 match netfilter_xtcompat Debian 11 (bullseye) 5.10.0-27 match fuse_legacy Debian 11 (bullseye) 5.10.0-27 match dirty_pipe Ubuntu 22.04.3 LTS 5.15.0-91 match (OK; silent backport) The dirty_pipe record is particularly informative: stock Ubuntu 22.04 ships 5.15.0-91-generic. Our version-only kernel_range check would say VULNERABLE (5.15.0 < 5.15.25 backport in our table). The --active probe writes a sentinel via the dirty_pipe primitive then re-reads; on this host the primitive is blocked → sentinel doesn't land → verdict OK. Ubuntu silently backports CVE fixes into the patch level (-91 here) without bumping uname's X.Y.Z. The targets.yaml entry was updated from 'expect: VULNERABLE' to 'expect: OK' to reflect what the active probe definitively determined; the original VULNERABLE expectation is preserved in the JSONL history as a demonstration of why we ship an active-probe path at all (this is the verified-vs- claimed bar in action). Plumbing fixes that landed in the same loop: - core/nft_compat.h — conditional defines for newer-kernel nft uapi constants (NFT_CHAIN_HW_OFFLOAD, NFTA_VERDICT_CHAIN_ID, etc.) that aren't in Ubuntu 20.04's pre-5.5 linux-libc-dev. Without this, nft_* modules failed to compile inside the verifier guest. Included from each nft module after <linux/netfilter/nf_tables.h>. - tools/verify-vm/Vagrantfile — wrap config in c.vm.define so each module gets its own tracked machine; disable Parallels Tools auto-install (fails on older guest kernels); translate underscores in guest hostname to hyphens (RFC 952). - tools/verify-vm/verify.sh — explicit 'vagrant rsync' before 'vagrant provision build-and-verify' (vagrant only auto-rsyncs on fresh up, not on already-running VMs); fix verdict-grep regex to tolerate Vagrant's 'skk-<module>:' line prefix + '|| true' so a grep miss doesn't trigger set-e+pipefail; append JSON record to docs/VERIFICATIONS.jsonl on every run. - tools/verify-vm/targets.yaml — dirty_pipe retargeted from ubuntu2004 + pinned 5.13.0-19 (no longer in 20.04's apt) to ubuntu2204 stock 5.15.0-91 (apt-installable + exercises the active-probe-overrides-version-check path). What's next for the verifier: - Mainline kernel.ubuntu.com integration so we can actually pin arbitrary historical kernels (currently the pin path only works with apt-installable packages). - Sweep the remaining ~18 verifiable modules and accumulate records. - Per-module verified_on counts in --explain header.	2026-05-23 15:46:14 -04:00
leviathan	5071ad4ba9	site: marketing-grade redesign with --explain showcase + animated hero ... Full rewrite of docs/index.html + style.css + new app.js + OG card. Hero - Animated gradient mesh background (3 drifting blurred blobs; respects prefers-reduced-motion). - Space Grotesk display wordmark with subtle white→gray gradient. - Eyebrow chip with pulsing dot showing current release. - Type-on-load install command with blinking cursor in a faux-terminal chrome (traffic-light dots, title bar, copy button). - Stats row that counts up from 0 on first paint: 31 modules, 10 KEV, 119 detection rules, 88 tests. - Primary CTA + secondary 'See --explain in action' + GitHub link. Trust strip - 'Grounded in authoritative sources' row: CISA KEV, NVD CVE API, MITRE ATT&CK, kernel.org stable tree, Debian Security Tracker, NIST CWE. Establishes the federal-data-source provenance. --explain showcase (flagship section) - Big terminal mockup that types out a real --explain nf_tables run line-by-line on scroll-into-view (45-95ms per line, easing). - Four annotation cards explaining each part: triage metadata, host fingerprint, detect() trace, OPSEC footprint. Bento grid (8 feature cards in a varied 3-col layout) - Auto-pick safest exploit (large card with code sample) - 119 detection rules (with animated per-format coverage bars) - CISA KEV prioritized (red-accented) - OPSEC notes per exploit - One host fingerprint, every module (large card with struct excerpt) - JSON for pipelines - No SaaS, no telemetry - Verifier ready (Vagrant + Parallels) Module corpus - Same green/yellow split as before, but every KEV-listed module pill now carries a ★ prefix + red-tinted border so 'actively exploited in the wild' is visible at a glance. Audience - 4 colored cards (red/blue/gray/purple) — pentesters, SOC, sysadmins, researchers — each with a deep link to the right doc. Verified-vs-claimed honesty callout - Featured gradient-bordered card restating the no-fabricated-offsets bar. ✓ icon, project's defining trust claim. Quickstart - Tabbed: install / scan / explain / auto / detect-rules. Each tab is a short, copy-ready snippet with inline comments. Roadmap timeline - Three columns: shipped / in flight / next. Shipped lists every feature from the last several sessions (--explain, OPSEC, CWE/ ATT&CK/KEV pipeline, 119 rules, host refactor, 88 tests, drift detector, VM scaffold). Next lists arm64 musl, mass-fleet aggregator, SIEM query templates, CI hardening. Footer - Four-column gradient footer (Brand / Project / Docs / Ethics) + bottom bar with credits to original PoC authors + license + repo link. Tech - Typography: Inter (UI) + JetBrains Mono (code) + Space Grotesk (display wordmark), all via Google Fonts with display=swap. - Palette: deep purple-tinted dark (#07070d) + emerald accent (#10b981) + cyan secondary (#06b6d4) + KEV-red (#ef4444) + violet (#a855f7) for threat-intel framing. - CSS: ~28KB unminified, custom-properties driven; gracefully degrades to single-column on every grid section at narrow widths. - JS: ~8KB vanilla, no frameworks. Respects prefers-reduced-motion everywhere. IntersectionObserver-driven scroll reveal and stat-count-up. - OG image: hand-authored SVG → rsvg-convert → 1200x630 PNG (121KB). Renders cleanly when shared on Twitter/LinkedIn/Slack. - 4 new files: app.js, og.svg, og.png; rewrites: index.html, style.css. Refreshed content: - v0.5.0 → v0.6.0 throughout. - '28 verified modules' → 31. - Adds KEV cross-ref, --explain, OPSEC, ATT&CK/CWE callouts that didn't exist in the previous version. HTML structure validated balanced (Python html.parser smoke test).	2026-05-23 11:42:56 -04:00
leviathan	ee3e7dd9a7	skeletonkey: --explain MODULE — single-page operator briefing ... One command that answers 'should we worry about this CVE here, what would patch it, and what would the SOC see if someone tried it'. Renders, for the specified module: - Header: name + CVE + summary - WEAKNESS: CWE id and MITRE ATT&CK technique (from CVE metadata) - THREAT INTEL: CISA KEV status (with date_added if listed) and the upstream-curated kernel_range - HOST FINGERPRINT: kernel + arch + distro from ctx->host plus every relevant capability gate (userns / apparmor / selinux / lockdown) - DETECT() TRACE (live): runs the module's detect() with verbose stderr enabled so the operator sees the gates fire in real time — 'kernel X is patched', 'userns blocked by AppArmor', 'no readable setuid binary', etc. - VERDICT: the result_t with a one-line operator interpretation that varies by outcome (OK / VULNERABLE / PRECOND_FAIL / TEST_ERROR each get their own framing) - OPSEC FOOTPRINT: word-wrapped .opsec_notes paragraph (from last commit) showing what an exploit would leave behind on this host - DETECTION COVERAGE: which of auditd/sigma/yara/falco have embedded rules for this module, with pointers to the --module-info / --detect-rules commands that dump the bodies Targeted at every audience the project is meant to serve: - Red team: opsec footprint + 'would this even reach' verdict in one screen - Blue team: paste-ready triage ticket with CVE / CWE / ATT&CK / KEV header and detection-coverage matrix - Researchers: the live trace shows the reasoning chain (predates check, kernel_range_is_patched lookup, userns gate) that drove the verdict — auditable without reading source - SOC analysts / students: a single self-contained briefing per CVE, no cross-referencing needed Implementation: - New mode MODE_EXPLAIN, new flag --explain MODULE - cmd_explain() composes the page from the existing module struct, cve_metadata_lookup() (federal-source triage data), ctx->host (cached fingerprint), and a live detect() call - print_wrapped() helper word-wraps the long .opsec_notes paragraph at 76 cols / 2-space indent - Help text + README quickstart + DETECTION_PLAYBOOK single-host recipe all updated to mention --explain Smoke tests: - macOS: --explain nf_tables shows full briefing; trace says 'Linux-only module — not applicable here'; verdict PRECOND_FAIL with the generic-precondition interpretation - Linux (docker gcc:latest): --explain nf_tables on a 6.12 host fires '[+] nf_tables: kernel 6.12.76-linuxkit is patched'; verdict OK with the 'this host is patched' interpretation - Both: --explain nope (unknown module) returns 1 with a clear 'no module ... Try --list' error - Both: 87 tests still pass (33 kernel_range + 54 detect on Linux, 33 + 0 stubbed on macOS) Closes the metadata + opsec + explain trio. The three together answer the 'best tool for red team, blue team, researchers, and more' framing.	2026-05-23 10:49:46 -04:00
leviathan	e4a600fef2	module metadata: CWE + ATT&CK + CISA KEV triage from federal sources ... Adds per-CVE triage annotations that turn SKELETONKEY's JSON output into something a SIEM/CTI/threat-intel pipeline can route on, and a KEV badge in --list so operators see at-a-glance which modules cover actively-exploited bugs. New tool — tools/refresh-cve-metadata.py: - Discovers CVEs by scanning modules/<dir>/ (no hardcoded list). - Fetches CISA's Known Exploited Vulnerabilities catalog (https://www.cisa.gov/.../known_exploited_vulnerabilities.csv). - Fetches CWE classifications from NVD's CVE API 2.0 (services.nvd.nist.gov), throttled to the anonymous 5-req/30s limit (~3 minutes for 26 CVEs). - Hand-curated ATT&CK technique mapping (T1068 default; T1611 for container escapes, T1082 for kernel info leaks — MITRE doesn't publish a clean CVE→technique feed). - Generates three outputs: docs/CVE_METADATA.json machine-readable, drift-checkable docs/KEV_CROSSREF.md human-readable table core/cve_metadata.c auto-generated lookup table - --check mode diffs the committed JSON against a fresh fetch for CI drift detection. New core API — core/cve_metadata.{h,c}: struct cve_metadata { cve, cwe, attack_technique, attack_subtechnique, in_kev, kev_date_added }; const struct cve_metadata *cve_metadata_lookup(const char *cve); Lookup keyed by CVE id, not module name — the metadata is properties of the CVE (two modules covering the same bug see the same metadata). The opsec_notes field stays on the module struct because exploit technique varies per-module (different footprints). Output surfacing: - --list: new KEV column shows ★ for KEV-listed CVEs. - --module-info (text): prints cwe / att&ck / 'in CISA KEV: YES (added YYYY-MM-DD)' between summary and operations. - --module-info / --scan (JSON): emits a 'triage' subobject with the full record, plus an 'opsec_notes' field at top level when set. Initial snapshot: - 10 of 26 modules cover KEV-listed CVEs (dirty_cow, dirty_pipe, pwnkit, sudo_samedit, ptrace_traceme, fuse_legacy, nf_tables, overlayfs, overlayfs_setuid, netfilter_xtcompat). - 24 of 26 have NVD CWE mappings; 2 unmapped (NVD has no weakness record for CVE-2019-13272 and CVE-2026-46300 yet). - All 26 mapped to an ATT&CK technique. Verification: - macOS local: 33 kernel_range + clean build, --module-info shows 'in CISA KEV: YES (added 2024-05-30)' for nf_tables, --list KEV column renders. - Linux (docker gcc:latest): 33 + 54 = 87 passes, 0 fails. Follow-up commits will add per-module OPSEC notes and --explain mode.	2026-05-23 10:38:01 -04:00
leviathan	8938a74d04	detection rules: YARA + Falco for the 6 highest-rank modules + playbook ... Closes the 'rules in the box' gap — the README has claimed YARA + Falco coverage but detect_yara and detect_falco were NULL on every module. This commit lights up both formats for the 6 highest-value modules (covering 10 of 31 registered modules via family-shared rules), and the existing operational playbook gains the format-specific deployment recipes + the cross-format correlation table. YARA rules (8 rules, 9 module-headers, 152 lines): - copy_fail_family — etc_passwd_uid_flip + etc_passwd_root_no_password (shared across copy_fail / copy_fail_gcm / dirty_frag_esp / dirty_frag_esp6 / dirty_frag_rxrpc) - dirty_pipe — passwd UID flip pattern, dirty-pipe-specific tag - dirtydecrypt — 28-byte ELF prefix match on tiny_elf[] + setuid+execve shellcode tail, detects the page-cache overlay landing - fragnesia — 28-byte ELF prefix on shell_elf[] + setuid+setgid+seteuid cascade, detects the 192-byte page-cache overlay - pwnkit — gconv-modules cache file format (small text file with module UTF-8// X// /tmp/...) - pack2theroot — malicious .deb (ar archive + SUID-bash postinst) + /tmp/.suid_bash artifact scan Falco rules (13 rules, 9 module-headers, 219 lines): - pwnkit — pkexec with empty argv + GCONV_PATH/CHARSET env from non-root - copy_fail_family — AF_ALG socket from non-root + NETLINK_XFRM from unprivileged userns + /etc/passwd modified by non-root - dirty_pipe — splice() of setuid/credential file by non-root - dirtydecrypt — AF_RXRPC socket + add_key(rxrpc) by non-root - fragnesia — TCP_ULP=espintcp from non-root + splice of setuid binary - pack2theroot — SUID bit set on /tmp/.suid_bash + dpkg invoked by packagekitd with /tmp/.pk-*.deb + 2x InstallFiles on same transaction Wiring: each module's .detect_yara and .detect_falco struct fields now point at the embedded string. The dispatcher dedups by pointer, so family-shared rules emit once across the 5 sub-modules. docs/DETECTION_PLAYBOOK.md augmented (302 -> 456 lines): - New 'YARA artifact scanning' subsection under SIEM integration with scheduled-scan cron pattern + per-rule trigger table - New 'Falco runtime detection' subsection with deploy + per-rule trigger table - New 'Per-module detection coverage' table — 4-format matrix - New 'Correlation across formats' section — multi-format incident signature per exploit (the 3-of-4 signal pattern) - New 'Worked example: catching DirtyDecrypt end-to-end' walkthrough from Falco page through yara confirmation, recovery, hunt + patch The existing operational lifecycle / SIEM patterns / FP tuning content is preserved unchanged — this commit only adds. Final stats: - auditd: 109 rule statements across 27 modules - sigma: 16 sigma rules across 19 modules - yara: 8 yara rules across 9 module headers (5 family + 4 distinct) - falco: 13 falco rules across 9 module headers The remaining 21 modules can gain YARA / Falco coverage incrementally by populating their detect_yara / detect_falco struct fields.	2026-05-23 00:47:13 -04:00
leviathan	97be306fd2	release: bump version to v0.6.0 ... This release captures the session's reliability + accuracy work on top of v0.5.0: - Shared host fingerprint (core/host.{h,c}): kernel/distro/userns gates / sudo + polkit versions, populated once at startup; every module consults ctx->host instead of doing its own probes. - Test harness (tests/test_detect.c, make test): 44 unit tests over mocked host fingerprints, wired into CI as a non-root step. - --auto upgrades: auto-enables --active, per-detect 15s timeout, fork-isolated detect + exploit so a crashing module can't tear down the dispatcher, per-module verdict table + scan summary. - --dry-run flag (preview without firing; --i-know not required). - Pinned mainline fix commits for the 3 ported modules (dirtydecrypt / fragnesia / pack2theroot) — detect() is now version-pinned with kernel_range tables, not precondition-only. - New modules: dirtydecrypt (CVE-2026-31635), fragnesia (CVE-2026-46300), pack2theroot (CVE-2026-41651). - macOS dev build works for the first time (all Linux-only code wrapped in #ifdef __linux__). - docs/JSON_SCHEMA.md: stable consumer contract for --scan --json. Version bump: - SKELETONKEY_VERSION = '0.6.0' in skeletonkey.c - README status line updated with the v0.6.0 changelog - docs/JSON_SCHEMA.md example refreshed	2026-05-23 00:22:18 -04:00
leviathan	c63ee72aa1	docs: JSON output schema (consumer contract for --scan --json) ... Adds docs/JSON_SCHEMA.md documenting the shape and stability promises of the JSON document --scan --json emits on stdout. The schema is already what the binary produces — this commit pins the contract so fleet-scan / SIEM consumers can rely on it across releases. What it covers: - Top-level object: { version, modules } and field stability. - Per-module entry: { name, cve, result } with type + stability. - The 6-value result enum (OK / TEST_ERROR / VULNERABLE / EXPLOIT_FAIL / PRECOND_FAIL / EXPLOIT_OK) and what each means semantically. - Process exit-code semantics for --scan (worst observed result becomes the exit code — lets a SIEM treat the binary exit as a single-host alert level). - Bash + jq one-liners for the common fleet-roll-up patterns. - A recommended Python consumer pattern with the forward-compat guidance (ignore unknown fields, treat unknown result strings as TEST_ERROR-equivalent). - Explicit stability promises: which fields cannot change without a major-version bump, what may be added in future minor releases, what consumers MUST tolerate. Verified against the live binary: --scan --json produces exactly the documented shape (top-level keys {modules, version}; per-module keys {cve, name, result}; result values come from the documented enum). 31 modules / 30 unique CVEs at v0.5.0. README's 'Sysadmins' audience row now links the schema doc: 'JSON output for CI gates ([schema](docs/JSON_SCHEMA.md))'.	2026-05-23 00:07:45 -04:00
leviathan	4f30d00a1c	core/host: shared host fingerprint refactor ... Adds core/host.{h,c} — a single struct skeletonkey_host populated once at startup and handed to every module callback via ctx->host. Replaces the per-detect uname / /etc/os-release / sysctl / userns-fork-probe calls scattered across the corpus with O(1) cached lookups, and gives the dispatcher one consistent view of the host. What's in the fingerprint: - Identity: kernel_version (parsed from uname.release), arch (machine), nodename, distro_id / distro_version_id / distro_pretty (parsed once from /etc/os-release). - Process state: euid, real_uid (defeats userns illusion via /proc/self/uid_map), egid, username, is_root, is_ssh_session. - Platform family: is_linux, is_debian_family, is_rpm_family, is_arch_family, is_suse_family (file-existence checks once). - Capability gates (Linux): unprivileged_userns_allowed (live fork+unshare probe), apparmor_restrict_userns, unprivileged_bpf_disabled, kpti_enabled, kernel_lockdown_active, selinux_enforcing, yama_ptrace_restricted. - System services: has_systemd, has_dbus_system. Wiring: - core/module.h forward-declares struct skeletonkey_host and adds the pointer to skeletonkey_ctx. Modules opt-in by including ../../core/host.h. - core/host.c is fully POD (no heap pointers) — uses a single file- static instance, returns a stable pointer on every call. Lazily populated on first skeletonkey_host_get(). - skeletonkey.c calls skeletonkey_host_get() at main() entry, stores in ctx.host before any register_*() runs. - cmd_auto's bespoke distro-fingerprint code (was an inline read_os_release helper) is replaced with skeletonkey_host_print_banner(), which emits a two-line banner of identity + capability gates. Migrations: - dirtydecrypt: kernel_version_current() -> ctx->host->kernel. - fragnesia: removed local fg_userns_allowed() fork-probe in favour of ctx->host->unprivileged_userns_allowed (no per-scan fork). Also pulls kernel from ctx->host. The PRECOND_FAIL message now notes whether AppArmor restriction is on. - pack2theroot: access('/etc/debian_version') -> ctx->host->is_debian_family; also short-circuits when ctx->host->has_dbus_system is false (saves the GLib g_bus_get_sync attempt on systems without system D-Bus). - overlayfs: replaced the inline is_ubuntu() /etc/os-release parser with ctx->host->distro_id comparison. Local helper preserved for symmetry / standalone builds. Documentation: docs/ARCHITECTURE.md gains a 'Host fingerprint' section describing the struct, the opt-in include pattern, and example detect() usage. ROADMAP --auto accuracy log notes the landing and flags remaining modules as an incremental follow-up. Build verification: - macOS (local): make clean && make -> Mach-O x86_64, 31 modules, banner prints with distro=?/? (no /etc/os-release). - Linux (docker gcc:latest + libglib2.0-dev): make clean && make -> ELF 64-bit, 31 modules. Banner prints with kernel + distro=debian/13 + 7 capability gates. dirtydecrypt correctly says 'predates the rxgk code added in 7.0'; fragnesia PRECOND_FAILs with '(host fingerprint)' annotation; pack2theroot PRECOND_FAILs on no-DBus; overlayfs reports 'not Ubuntu (distro=debian)'.	2026-05-22 23:18:00 -04:00
leviathan	9a4cc91619	pack2theroot (CVE-2026-41651) + --auto accuracy work ... Adds the third ported module — Pack2TheRoot, a userspace PackageKit D-Bus TOCTOU LPE — and spends real effort hardening --auto so its detect step gives an accurate, robust verdict before deploying. pack2theroot (CVE-2026-41651): - Ported from the public Vozec PoC (github.com/Vozec/CVE-2026-41651). Original disclosure by the Deutsche Telekom security team. - Two back-to-back InstallFiles D-Bus calls (SIMULATE then NONE) overwrite the cached transaction flags between polkit auth and dispatch. GLib priority ordering makes the overwrite deterministic, not a timing race; postinst of the malicious .deb drops a SUID bash in /tmp. - detect() reads PackageKit's VersionMajor/Minor/Micro directly over D-Bus and compares against the pinned fix release 1.3.5 (commit 76cfb675). This is a high-confidence verdict, not precondition-only. - Debian-family only (PoC builds its own .deb in pure C; ar/ustar/ gzip-stored inline). Cleanup removes /tmp .debs + best-effort unlinks /tmp/.suid_bash + sudo -n dpkg -r the staging packages. - Adds an optional GLib/GIO build dependency. The top-level Makefile autodetects via `pkg-config gio-2.0`; when absent the module compiles as a stub returning PRECOND_FAIL. - Embedded auditd + sigma rules cover the file-side footprint (/tmp/.suid_bash, /tmp/.pk-*.deb, non-root dpkg/apt execve). --auto accuracy improvements: - Auto-enables --active before the scan. Per-module sentinel probes (page-cache /tmp files, fork-isolated namespace mounts) turn version-only checks into definitive verdicts, so silent distro backports don't fool the scan and --auto won't pick blind on TEST_ERROR. - Per-module verdict printing — every module's result is shown (VULNERABLE / patched / precondition / indeterminate), not just VULNERABLE rows. Operator sees the full picture. - Scan-end summary line: "N vulnerable, M patched/n.a., K precondition-fail, L indeterminate" with a separate callout when modules crashed. - Distro fingerprint added to the auto banner (ID + VERSION_ID from /etc/os-release alongside kernel/arch). - Fork-isolated detect() — each detector runs in a child process so a SIGILL/SIGSEGV in one module's probe is contained and the scan continues. Surfaced live while testing: entrybleed's prefetchnta KASLR sweep SIGILLs on emulated CPUs (linuxkit on darwin); without isolation the whole --auto died at module 7 of 31. With isolation the scan reports "detect() crashed (signal 4) — continuing" and finishes cleanly. module_safety_rank additions: - pack2theroot: 95 (userspace D-Bus TOCTOU; dpkg + /tmp SUID footprint — clean but heavier than pwnkit's gconv-modules-only path). - dirtydecrypt / fragnesia: 86 (page-cache writes; one step below the verified copy_fail/dirty_frag family at 88 to prefer verified modules when both apply). Docs: - README badge / tagline / tier table / ⚪ block / example output / v0.5.0 status — all updated to "28 verified + 3 ported". - CVES.md counts line, the ported-modules note (now calling out pack2theroot's high-confidence detect vs. precondition-only for the page-cache pair), inventory row, operations table row. - ROADMAP Phase 7+: pack2theroot moved out of carry-overs into the "landed (ported, pending VM verification)" group; added a new "--auto accuracy work" subsection documenting the dispatcher hardening landed in this commit. - docs/index.html: scanning-count example bumped to 31, status line updated to mention 3 ported modules. Build verification: full `make clean && make` in `docker gcc:latest` with libglib2.0-dev installed: links into a 31-module skeletonkey ELF (413KB), `--list` shows all modules including pack2theroot, `--detect-rules --format=auditd` emits the new pack2theroot section, `--auto --i-know --no-shell` exercises the new banner + active probes + verdict table + fork isolation + scan summary end-to-end. Only build warning is the pre-existing `-Wunterminated-string-initialization` in dirty_pipe (not introduced here).	2026-05-22 22:42:07 -04:00
leviathan	ac557b67d0	review pass: fidelity + credits + count consistency for ported modules ... Three-agent rigorous review of the dirtydecrypt + fragnesia ports plus repo-wide doc consistency, followed by a full Linux build verification. dirtydecrypt (NOTICE + detection rules): - NOTICE.md: removed an unsupported "Zellic co-founder" detail and a fabricated disclosure-date narrative; tightened phrasing of the Zellic + V12 credit; noted that upstream poc.c carries no author/license header of its own. - Embedded auditd + sigma rules and detect/sigma.yml broadened to cover every binary in dd_targets[] (added /usr/bin/mount, /usr/bin/passwd, /usr/bin/chsh) and added the b32 splice rule, so the embedded ruleset matches the on-disk reference and the carrier list the exploit actually targets. - Exploit primitive verified byte-for-byte against the V12 PoC (tiny_elf[] identical, all rxgk/XDR/fire/pagecache_write logic token-identical). docker gcc:latest compile of the Linux path: COMPILE_OK, zero warnings. fragnesia: review found no defects. Exploit primitive byte-identical to the V12 PoC (shell_elf[] 192 bytes identical, AF_ALG GCM keystream table + userns/netns/XFRM + receiver/sender/run_trigger_pair all faithful). The deliberate omissions (ANSI TUI, CLI arg parsing) drop nothing exploit-critical. docker gcc:latest compile: COMPILE_OK; full project build links into a working skeletonkey ELF and --list shows the module registered correctly. Repo docs (README.md / CVES.md / ROADMAP.md): - Chose to keep "28 verified" as the headline; the two ported modules are represented as a separate clearly-labelled tier ("ported-but-unverified") that is explicitly excluded from the 28-module verified counts. README + CVES.md + ROADMAP.md now tell one consistent story. - Filled a pre-existing documentation gap: sudo_samedit, sequoia, sudoedit_editor, vmwgfx were registered + built but absent from CVES.md's inventory + operations tables. Added rows synthesized from each module's .cve / .summary / .kernel_range fields. - ROADMAP Phase 8 "7 🟡 PRIMITIVE modules" → "14"; added a "Landed since v0.1.0" group; moved vmwgfx out of the stale carry-overs. docs site (docs/index.html): - Stat box "28 / total modules" → "28 / verified modules" (the 14+14 breakdown now sums to the headline consistently). - Terminal example "scanning 28 modules" → "scanning 30 modules" (was factually wrong — the binary literally prints module_count() which is 30). - Status line: updated to mention the 2 ported-but-unverified modules and mirror the README phrasing. - docs/LAUNCH.md left as a dated v0.5.0 launch snapshot. Build verification: `docker run gcc:latest make clean && make` — links into a 30-module skeletonkey ELF on Linux. macOS dev box still hits the pre-existing dirty_pipe header gap; unchanged. .gitignore: added /skeletonkey to exclude the top-level build artifact (the existing modules/*/skeletonkey only covered per-module binaries; the root one was getting picked up by `git add -A`).	2026-05-22 18:41:37 -04:00
leviathan	33f81aeb69	site: revert CVE table → pill grid ... The sortable table was denser but lost the visual scan-ability of the color-coded pill grid. Restoring the pill view: two grouped sections (🟢 / 🟡) each showing every module name as a pill. Drops the table-sort JS (~25 lines) and the .cve-table CSS block.	2026-05-17 02:25:25 -04:00
leviathan	58fb2e0951	site: simplify nav + add sortable CVE chart ... nav: removed Releases / CVEs / Defenders links — kept only a right-aligned GitHub link with the Octocat SVG icon. index.html: replaced pill-grid corpus view with a proper sortable table — Year, CVE, Bug, Module, Tier columns. Click headers to sort. Defaults to Year descending. 28 rows covering 2016 → 2026. style.css: added .nav-github (border-pill style) + table styles (sortable headers with arrow indicators, hover rows, mobile- responsive font-size + overflow-x scroll). JS for sort is ~25 lines vanilla — no library.	2026-05-17 02:22:54 -04:00
leviathan	2904fa159c	site: GitHub Pages landing page ... Single-page static site under /docs/, served by GitHub Pages from the main branch /docs source. docs/index.html: hero with one-liner + copy button, why-this-exists, corpus stats + module pills (14 🟢 + 14 🟡), audience cards (red/blue/sysadmin/CTF), terminal-shape worked example, verified-vs-claimed bar, quickstart commands, status, footer. docs/style.css: dark theme matching GitHub's color palette (#0d1117 bg, #c9d1d9 text). System sans for prose, ui-monospace for code. Mobile-responsive with grid breakpoints. No JS framework, no external fonts, no analytics. docs/.nojekyll: disable Jekyll so the static HTML is served verbatim and the existing /docs/*.md files stay as raw markdown (viewable via GitHub UI, not the Pages site).	2026-05-17 02:14:15 -04:00
leviathan	95135213e5	launch: README polish + CONTRIBUTING + LAUNCH.md ... README.md: badges (release / license / module-count / platform), sharpened hero stating value prop in one sentence, audience framing for red team / sysadmin / blue team. CONTRIBUTING.md (new): what we accept (offsets, modules, detection rules, bug reports) and what we don't (untested EXPLOIT_OK, fabricated offsets, 0days, undisclosed CVEs). docs/LAUNCH.md (new): ~600-word HN/blog launch post. Copy-paste ready. Explains the verified-vs-claimed bar + --auto + the operator-populated offset table approach. GitHub repo description + 11 topics set via gh repo edit so the repo is discoverable in topic searches (linux-security, privilege-escalation, cve, redteam, blueteam, etc.).	2026-05-17 01:59:25 -04:00
leviathan	9593d90385	rename: IAMROOT → SKELETONKEY across the entire project ... Breaking change. Tool name, binary name, function/type names, constant names, env vars, header guards, file paths, and GitHub repo URL all rebrand IAMROOT → SKELETONKEY. Changes: - All "IAMROOT" → "SKELETONKEY" (constants, env vars, enum values, docs, comments) - All "iamroot" → "skeletonkey" (functions, types, paths, CLI) - iamroot.c → skeletonkey.c - modules/*/iamroot_modules.{c,h} → modules/*/skeletonkey_modules.{c,h} - tools/iamroot-fleet-scan.sh → tools/skeletonkey-fleet-scan.sh - Binary "iamroot" → "skeletonkey" - GitHub URL KaraZajac/IAMROOT → KaraZajac/SKELETONKEY - .gitignore now expects build output named "skeletonkey" - /tmp/iamroot-* tmpfiles → /tmp/skeletonkey-* - Env vars IAMROOT_MODPROBE_PATH etc. → SKELETONKEY_* New ASCII skeleton-key banner (horizontal key icon + ANSI Shadow SKELETONKEY block letters) replaces the IAMROOT banner in skeletonkey.c and README.md. VERSION: 0.3.1 → 0.4.0 (breaking). Build clean on Debian 6.12.86. `skeletonkey --version` → 0.4.0. All 24 modules still register; no functional code changes — pure rename + banner refresh.	2026-05-16 22:43:49 -04:00
leviathan	9d88b475c1	v0.3.1: --dump-offsets tool + NOTICE.md per module ... The README has been claiming "each module credits the original CVE reporter and PoC author in its NOTICE.md" since v0.1.0, but only copy_fail_family actually shipped one. Fixed. modules/<name>/NOTICE.md (×19 new + 1 existing): per-module research credit covering CVE ID, discoverer, original advisory URL where public, upstream fix commit, IAMROOT's role. iamroot.c: new --dump-offsets subcommand. Resolves kernel offsets via the existing core/offsets.c four-source chain (env → /proc/kallsyms → /boot/System.map → embedded table), then emits a ready-to-paste C struct entry for kernel_table[]. Run once as root on a target kernel build; upstream via PR. Eliminates fabricating offsets — every shipped entry traces back to a `iamroot --dump-offsets` invocation on a real kernel. docs/OFFSETS.md: documents the --dump-offsets workflow. CVES.md: notes the NOTICE.md convention + offset dump tool. iamroot.c: bump IAMROOT_VERSION 0.3.0 → 0.3.1.	2026-05-16 22:33:43 -04:00
leviathan	e2a3d6e94f	release: v0.2.0 — --full-chain root-pop opt-in across 7 🟡 modules ... iamroot.c: bump IAMROOT_VERSION 0.1.0 → 0.2.0 CVES.md: redefine 🟡 to note --full-chain capability + docs/OFFSETS.md README.md: update Status section for v0.2.0 docs/OFFSETS.md: new doc — env-var/kallsyms/System.map/embedded-table resolution chain + operator workflow for populating offsets per kernel build + sentinel-based success arbitration. All 7 🟡 modules now expose `--full-chain`. Default behavior unchanged.	2026-05-16 22:06:14 -04:00
leviathan	ea5d021f0c	tools/iamroot-fleet-scan.sh + docs/DETECTION_PLAYBOOK.md ... iamroot-fleet-scan.sh — bash wrapper that scp's the iamroot binary to a host list, ssh-runs --scan --json on each, aggregates results into a single JSON document. Supports: - hosts list from file or stdin - user@host:port syntax - parallel xargs execution (default -P 4) - ssh key / extra ssh opts pass-through - --no-sudo for hosts where root isn't required - --summary-only to suppress per-host detail - --no-cleanup to leave the binary on disk Critical fix during smoke-test: iamroot's exit codes are SEMANTIC (0=OK, 2=VULNERABLE, 4=PRECOND_FAIL, 5=EXPLOIT_OK). The wrapper must NOT treat nonzero exit as a transport failure; success is defined by 'stdout contains valid JSON', failure by 'stdout empty'. Verified end-to-end on kctf-mgr → kctf-fuzz: fleet-scan reports ok=1, failed=0, summary.vulnerable groups by CVE: copy_fail_gcm, dirty_frag_esp×2, entrybleed. Per-host detail included. docs/DETECTION_PLAYBOOK.md — operational integration guide: - Lifecycle diagram (inventory → scan → fleet scan → deploy/mitigate/upgrade → monitor) - Recipes by team size: single host, small fleet, large fleet - SIEM integration patterns: Splunk, Elastic, Sigma - Auditd-event lookup commands per module key - VULNERABLE decision tree (patch vs mitigate vs compensate) - Mitigation revert procedures + side-effect table - False-positive tuning table per rule key - Pre-patch quarantine pattern - Maintenance contract / module-shipping SLA	2026-05-16 20:29:48 -04:00
leviathan	f1bd896ca8	Phase 7: Pwnkit FULL exploit (Qualys-style PoC) + DEFENDERS.md ... Pwnkit: 🔵 → 🟢 - Implements the canonical Qualys-style PoC end-to-end: 1. Locate setuid pkexec 2. mkdtemp working directory under /tmp 3. Detect target's gcc/cc (fail-soft if absent) 4. Write payload.c (gconv constructor: unsetenv hostile vars, setuid(0), execle /bin/sh -p with clean PATH) 5. gcc -shared -fPIC payload.c -o pwnkit/PWNKIT.so 6. Write gconv-modules cache pointing UTF-8// → PWNKIT// 7. execve(pkexec, NULL_argv, envp{GCONV_PATH=workdir/pwnkit, PATH=GCONV_PATH=., CHARSET=PWNKIT, SHELL=pwnkit}) → argc=0 triggers argv-overflow-into-envp; pkexec re-execs with PATH set to our tmpdir; libc's iconv loads PWNKIT.so as root; constructor pops /bin/sh with uid=0. - Cleanup: removes /tmp/iamroot-pwnkit-* workdirs. - Auto-refuses on patched hosts (re-runs detect() first). - GCC -Wformat-truncation warnings fixed by sizing path buffers generously (1024/2048 bytes — way more than needed in practice). Verified end-to-end on kctf-mgr (polkit 126 = patched): iamroot --exploit pwnkit --i-know → detect() says fixed → refuses cleanly. Correct behavior. Vulnerable-kernel validation is Phase 4 CI matrix work. docs/DEFENDERS.md — blue-team deployment guide: - TL;DR: scan, deploy rules, mitigate, watch - Operations cheat sheet (--list, --scan, --detect-rules, --mitigate) - Audit-key table mapping rule keys to modules to caught behavior - Fleet-scanning recipe (ssh + jq aggregation) - Known false-positive shapes per rule with tuning hints CVES.md: pwnkit row updated 🔵 → 🟢. ROADMAP.md: Phase 7 Pwnkit checkbox marked complete.	2026-05-16 20:13:11 -04:00
leviathan	cf30b249de	Initial skeleton: README, CVE inventory, roadmap, ARCH, ethics + copy_fail_family module absorbed from DIRTYFAIL	2026-05-16 19:26:24 -04:00