136 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Kara Zajac	d466fbfdcb	docs: cache-bust og:image to ?v=2 (force fresh card past Cloudflare/social cache) ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 17:27:15 -04:00
Kara Zajac	a8bc81c54c	docs: regenerate og.png with skeletonkey.netslum.io URL ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 17:25:55 -04:00
Kara Zajac	b7027a1749	docs: point OG/canonical URLs to skeletonkey.netslum.io (new home) ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 17:15:53 -04:00
KaraZajac	03324c8542	modules: add ghostlock (CVE-2026-43499, "GhostLock" rtmutex/futex requeue-PI stack UAF) ... Adds the ghostlock module for CVE-2026-43499 ("GhostLock", VEGA / Nebula Security's "IonStack part II") — a ~15-year race UAF on kernel STACK memory in the rtmutex/futex requeue-PI path (kernel/locking/rtmutex.c). On the -EDEADLK deadlock-rollback, remove_waiter() runs against `current` instead of the waiter task, so a concurrent sched_setattr()-driven PI-chain priority walk on another CPU clears pi_blocked_on on the wrong task and leaves an on-stack rt_mutex_waiter dangling. Reachable by any unprivileged user (CVSS 7.8, PR:L) — plain futex(2) + sched_setattr(2), no userns/CONFIG beyond CONFIG_FUTEX_PI. The corpus's first rtmutex/futex-PI module and first kernel-stack UAF (all others are heap/slab). Introduced 2.6.39; fixed 3bfdc63936dd (7.1-rc1), stable backports 7.0.4 / 6.18.27 / 6.12.86 / 6.6.140 / 6.1.175; 5.15/5.10/5.4/4.19 affected with no upstream fix. CWE-416; not in KEV. detect() is a pure version gate over the five-branch backport table. exploit() forks an isolated child that (A) deterministically confirms the -EDEADLK remove_waiter() rollback path is reachable (safe — no concurrent walk means no dangling pointer; validated on real hardware) then (B) exercises the actual race a hard-bounded 24 iters / 2s with a sibling-CPU sched_setattr(SCHED_BATCH) storm, and stops. Deliberately under-driven: no copy_from_user widening, no stack-frame spray/reoccupation, and the KernelSnitch leak -> forged-waiter -> fops/ashmem/pipe R/W -> cred-patch chain (Android/Pixel-specific, per-build offsets) is NOT bundled. Returns EXPLOIT_FAIL. Lowest --auto safety rank (11) — a won race corrupts the kernel stack. Unlike most races it ships a real detection signature (futex requeue-PI returning EDEADLK + sibling sched_setattr); auditd/sigma anchor on sched_setattr, falco/eBPF on the EDEADLK tell; no yara. Wired: registry, Makefile, safety rank 11, version 0.9.13, 9 detect() test rows (incl. 6.13.0 -> VULNERABLE, the multi-branch "newer than all" case), CVE metadata (CWE-416 / T1068 / not-KEV; cve_metadata.c + KEV_CROSSREF.md regenerated -> 13 of 40), README + CVES.md + website counts (45 modules / 40 CVEs), RELEASE_NOTES v0.9.13, verify-vm target. Also corrects pre-existing docs/index.html drift left by v0.9.12 (body counts stuck at 43/38 and a missing bad_epoll corpus pill). Tests: 33 kernel_range + 101 detect, all pass. Credit: VEGA / Nebula Security (nebusec.ai, NebuSec/CyberMeowfia, Apache-2.0); upstream fix 3bfdc63936dd (Keenan Dong / Thomas Gleixner). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KUq4DGXSPBmPkAyJ9WnM9n v0.9.13	2026-07-13 15:43:00 -04:00
KaraZajac	95589e26cb	modules: add bad_epoll (CVE-2026-46242, "Bad Epoll" epoll teardown race UAF) ... Jaeyoung Chung's kernelCTF "Bad Epoll": a race-condition use-after-free in fs/eventpoll.c. ep_remove() clears file->f_ep under f_lock but keeps using the file (hlist_del_rcu + unlock) while a concurrent __fput() frees the still-referenced struct eventpoll. Reachable by any unprivileged user with no userns / CONFIG / capability; weaponised via cross-cache to a struct file, /proc/self/fdinfo arb-read, and ROP. Introduced 58c9b016e128 (6.4), fixed a6dc643c6931 (7.1-rc1), stable backport 7.0.13. CWE-416; not in KEV. The corpus's first epoll / VFS-teardown module. Shipped as a reconstructed, deliberately under-driven trigger on the stackrot / nft_catchall contract: detect() is a pure version gate (>= 6.4 and below the on-branch fix; no userns precondition -- epoll needs none); exploit() forks a CPU-pinned child that exercises the ep_remove-vs-__fput close window a hard-bounded 48 attempts / 2s and returns EXPLOIT_FAIL. It does not grind the race to a win, does not do the cross-cache reclaim, and does not bundle the fdinfo R/W + ROP (a won race frees a live struct file and rarely trips KASAN -> silent-corruption risk). Wired: registry, Makefile, safety rank (12 -- lowest in the corpus; a kernel race is the least predictable class), 5 detect() test rows (version gating), CVE metadata (sorted insert, CWE-416 / T1068 / not-KEV), README + CVES.md + website counts (44/39), RELEASE_NOTES v0.9.12, and a verify-vm target (sweep pending). Detection rules are intentionally weak/structural (epoll ubiquitous, rarely KASAN) -- post-exploitation euid-0 transition, no yara. Also corrects pre-existing README drift in the "not yet verified" count (8 -> 11). Not VM-verified, so the verified count stays 28 of 39. Version 0.9.12. Credit: Jaeyoung Chung (J-jaeyoung). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KUq4DGXSPBmPkAyJ9WnM9n v0.9.12	2026-07-04 19:35:33 -04:00
KaraZajac	4d0a0e2443	modules: add nft_catchall (CVE-2026-23111, nf_tables catch-all abort UAF) ... The newest nftables LPE: a use-after-free in the nf_tables transaction- abort path. An inverted condition (a stray '!') in nft_map_catchall_activate() makes the abort path process active catch-all map elements instead of skipping them; a catch-all GOTO element drives a chain's use-count to zero so a following DELCHAIN frees it while the catch-all verdict still references it -> UAF, escalatable from an unprivileged user (userns + nftables) via modprobe_path/selinux_state ROP. Fixed upstream by f41c5d1; CWE-416, CVSS 7.8; not in CISA KEV. Public reproduction by FuzzingLabs. Takes the corpus to 43 modules / 38 CVEs. 🟡 reconstructed trigger, primitive-only, NOT VM-verified — same contract as nf_tables (CVE-2024-1086). detect() version-gates (catch-all elems ~5.13; Debian backports 6.1.164/6.12.73/6.18.10, 7.0+ inherits) AND requires unprivileged user_ns clone (else PRECOND_FAIL). exploit() forks an isolated child, builds a verdict map with a catch-all GOTO element, provokes an aborting batch to drive the abort-path UAF, observes slabinfo, and returns EXPLOIT_FAIL — the per-kernel leak + R/W + modprobe_path ROP is not bundled. kernel_range table verified drift-clean against the live Debian tracker (the 6.18 branch / 6.18.10 fix is the real forky/sid backport; the earlier 7.0.10 figure was wrong). Wired: registry, Makefile, safety rank (35), 6 detect() test rows (version + userns gating), CVE_METADATA.json + cve_metadata.c + KEV_CROSSREF.md (sorted insert, CWE-416/T1068/not-KEV), README + CVES.md + website counts (43/38) + yellow pill, RELEASE_NOTES v0.9.11, verify-vm target. Credit: FuzzingLabs + upstream fix f41c5d1. Version 0.9.11. v0.9.11	2026-06-08 17:42:19 -04:00
KaraZajac	050731396d	docs: record partial VM verification of cifswitch (CVE-2026-46243) ... Verified 2026-06-08 on Ubuntu 24.04.4 / kernel 6.8.0-117-generic under QEMU/HVF (offline: cloud image + payload iso, no guest networking): - modprobe cifs registers the cifs.spnego key type (cifs-utils not needed to reach the primitive). - Independent python3 ctypes add_key('cifs.spnego', forged uid/creduid/upcall_target) ACCEPTED (user-key control also accepted); module exploit() independently reported 'primitive CONFIRMED' then the honest EXPLOIT_FAIL. - detect() returned PRECOND_FAIL without cifs-utils and VULNERABLE under SKELETONKEY_CIFS_ASSUME_PRESENT=1. Still pending (so cifswitch stays 🟡 and is NOT counted as a verified end-to-end CVE; verified count stays 28 of 37): a patched kernel (>=6.12.90/7.0.10) to prove add_key is REJECTED there (probe discriminates fixed-from-vulnerable), and the full namespace+NSS root-pop. Recorded in NOTICE.md, CVES.md, RELEASE_NOTES.md, and tools/verify-vm/targets.yaml.	2026-06-08 13:53:29 -04:00
KaraZajac	ada56b0db3	modules: add cifswitch (CVE-2026-46243, Asim Manizada's CIFSwitch) ... CIFSwitch is the newest kernel-7-era LPE not already in the corpus: a ~19-year-old logic flaw in fs/smb/client/cifs_spnego.c where the cifs.spnego request-key type accepts key descriptions created by userspace (add_key(2)/request_key(2)) without verifying the request came from the in-kernel CIFS client. The description's authority-bearing fields (pid/uid/creduid/upcall_target) are trusted by the root cifs.upcall helper; with user+mount namespace tricks an unprivileged user coerces cifs.upcall into loading an attacker NSS module as root. Fixed upstream by 3da1fdf4efbc (merged 7.1-rc5); CWE-20; not in CISA KEV. Takes the corpus to 42 modules / 37 CVEs. 🟡 honest port — full chain not VM-verified. detect() gates on the kernel version (Debian backports 5.10.257/6.1.174/6.12.90/7.0.10) AND on the cifs userspace path (cifs.upcall / cifs.spnego request-key rule), so a vulnerable kernel without cifs-utils is PRECOND_FAIL not a false positive (override via SKELETONKEY_CIFS_ASSUME_PRESENT=1/0). exploit() fires only the non-destructive add_key(2) cifs.spnego probe (no upcall, loads nothing, revoked immediately) and returns EXPLOIT_FAIL without a euid-0 witness — the namespace+NSS root-pop is not bundled until VM-verified. --mitigate blocklists the cifs module; --cleanup reverts. Wired everywhere: registry, Makefile, safety rank (86), 6 detect() test rows (env-driven precondition override), CVE_METADATA.json + cve_metadata.c + KEV_CROSSREF.md (sorted insert, CWE-20/T1068/not-KEV), README + CVES.md + website counts (42/37) and a yellow module pill, RELEASE_NOTES v0.9.10, verify-vm target (sweep pending). Credit: Asim Manizada. Version 0.9.10. v0.9.10	2026-06-08 11:07:27 -04:00
KaraZajac	28a9289989	fix: normalize CVE_METADATA.json to sorted order (drift-check) ... The weekly drift-check stayed red after v0.9.9's KEV+CWE fixes because of a latent ordering bug: sudo_host (CVE-2025-32462), added in v0.9.8, was appended to the end of CVE_METADATA.json instead of its sorted position. check_drift compares the record list in discover_cves() sorted order, so the misplaced entry read as drift independent of its field values. Regenerated via tools/refresh-cve-metadata.py — sorted order restored, all field values reconfirmed against CISA KEV + NVD in a clean fetch. v0.9.9	2026-06-08 10:30:25 -04:00
KaraZajac	e457b22c1f	release v0.9.9: install.sh needs no sudo + CVE metadata drift fix ... install.sh never escalates to sudo. The installer defaulted to /usr/local/bin and fell back to `sudo mv`, prompting for a password on exactly the unprivileged accounts a privilege-escalation tool targets. It now uses /usr/local/bin only when already writable and otherwise installs to a per-user $HOME/.local/bin (honoring XDG_BIN_HOME), no sudo ever. An explicit SKELETONKEY_PREFIX is honored and errors rather than escalating. The documented one-liner prepends ~/.local/bin to PATH so it resolves on a fresh login, and the quickstart drops the misleading sudo from --scan / --audit / --auto. CVE metadata drift (the failing weekly drift-check): - CVE-2022-0492 (cgroup_release_agent) entered CISA KEV 2026-06-02; corpus now 13 of 36 modules cover KEV-listed CVEs. - CVE-2026-46333 (ptrace_pidfd) gained CWE-269 from NVD (was unclassified at module-add time). Refreshed CVE_METADATA.json, generated cve_metadata.c, and KEV_CROSSREF.md; README + website KEV counts and version bumped to 0.9.9.	2026-06-08 10:16:24 -04:00
KaraZajac	60579f1602	release v0.9.8: two new LPE modules (ptrace_pidfd, sudo_host) ... Tags the two modules added this cycle (already on main): ptrace_pidfd (CVE-2026-46333, Qualys __ptrace_may_access/pidfd_getfd credential-fd theft, bd63aab) and sudo_host (CVE-2025-32462, Stratascale sudo -h/--host policy bypass, dd5f4fa). This commit bumps the version strings (skeletonkey.c, README, docs/index.html) and prepends the v0.9.8 RELEASE_NOTES entry. Corpus is now 41 modules / 36 CVEs / 28 verified. Tagging fires release.yml, which rebuilds + publishes the four prebuilt binaries via the Node-24 artifact actions bumped in v0.9.7. v0.9.8	2026-06-02 09:03:05 -04:00
KaraZajac	dd5f4fa06d	modules: add sudo_host (CVE-2025-32462, Stratascale sudo --host policy bypass) ... Second new module this cycle; sibling of sudo_chwoot (CVE-2025-32463, same Stratascale/Rich Mirch disclosure). sudo's -h/--host option — meant only to pair with -l/--list — was honored when running a command, so a sudoers rule scoped to a host other than the current machine (and not ALL) is usable via 'sudo -h <host> <cmd>' for local root. Affects sudo 1.8.8 -> 1.9.17p0; fixed 1.9.17p1. CWE-863, CVSS 8.8 (not in KEV). detect(): version-gate [1.8.8, 1.9.17p0] via ctx->host->sudo_version (the host-restricted rule itself isn't probeable unprivileged, so VULNERABLE means 'vulnerable sudo present'). exploit(): discovers an abusable host-restricted rule from readable sudoers (or SKELETONKEY_SUDO_HOST), witnesses with 'sudo -n -h <host> id -u', pops 'sudo -h <host> /bin/bash' (SKELETONKEY_SUDO_CMD) only on a uid-0 witness; honest EXPLOIT_FAIL + operator guidance otherwise. Shared 'sudo' family; structural, arch=any; safety rank 96. auditd/sigma/falco rules, NOTICE.md (Rich Mirch / Stratascale) + MODULE.md, 4 detect() test rows. Wiring: registry, Makefile, cve_metadata (+JSON), verify-vm/targets.yaml (ubuntu1804 sudo 1.8.21p2 target, sweep pending). Docs: README + CVES.md + docs/index.html counts 40->41 modules / 35->36 CVEs; not-yet-verified lists + corpus pill.	2026-06-02 08:43:09 -04:00
KaraZajac	3d9db6b93e	tests: add ptrace_pidfd (CVE-2026-46333) detect() coverage ... Six detect() rows over synthetic host fingerprints: predates-gate at pidfd_getfd's 5.6 introduction (4.4 / 5.5.99 -> OK), vulnerable window (5.15.5 / 6.12.87 -> VULNERABLE), exact trixie backport (6.12.88 -> OK), and mainline inheritance (7.1.0 -> OK). Matches the harness per-module coverage convention; clears ptrace_pidfd from the coverage-gap report.	2026-06-02 08:29:10 -04:00
KaraZajac	bd63aabd64	modules: add ptrace_pidfd (CVE-2026-46333, Qualys ptrace/pidfd_getfd cred-steal) ... New module for Qualys's 2026-05-20 disclosure: a __ptrace_may_access logic flaw leaves a process dropping privileges briefly reachable past its dumpable boundary; pidfd_getfd(2) steals root-opened fds / authenticated channels from it. Default-distro, no userns, arch-agnostic (fd-steal, no shellcode). detect(): version-pinned, predates-gate at pidfd_getfd's 5.6 introduction; kernel_range from Debian backports (5.10.251/6.1.172/6.12.88/7.0.7), drift-check clean. exploit(): spawns a setuid victim, pidfd_open()s it, sweeps pidfd_getfd() over its fd table during the cred-drop window, reports any uid-0-owned fd captured from a non-root context. Honest EXPLOIT_FAIL without a euid-0 witness; not yet VM-verified. mitigate(): yama ptrace_scope=2; cleanup() reverts. auditd/sigma/falco rules, NOTICE.md (Qualys TRU credit) + MODULE.md, safety rank 84. Wiring: registry, Makefile, cve_metadata (+JSON source), verify-vm/targets.yaml (ubuntu2204 + mainline 5.15.5 target, sweep pending). Docs: README + CVES.md + docs/index.html counts 39->40 modules / 34->35 CVEs; added to not-yet-verified lists + corpus pill.	2026-06-02 08:26:24 -04:00
KaraZajac	1663df69d1	release v0.9.7: kernel_range drift fix + CI Node 24 readiness ... Tags the maintenance work landed since v0.9.6. The fragnesia drift fix (35c33df) and checkout v4->v6 bump (6c148e2) are already on main; this commit adds the remaining CI Node-24 bumps + version strings. release.yml: upload-artifact v4->v7, download-artifact v4->v8, softprops/action-gh-release v2->v3 (last of the Node-20-era actions; GitHub forces node24 on 2026-06-16). Reviewed each changelog — our default-zip/unique-name upload + full-set download is unaffected by the major-version breaking changes (opt-in direct uploads, download-by-ID path). Version bumped to 0.9.7 (skeletonkey.c, README, docs/index.html) + v0.9.7 RELEASE_NOTES entry. Tagging this commit fires release.yml — the end-to-end test of the new artifact actions, incl. the Alpine/musl static job under node24. v0.9.7	2026-06-01 11:55:31 -04:00
KaraZajac	6c148e276a	ci: bump actions/checkout v4 -> v6 (Node 24 readiness) ... GitHub forces the Node 24 runtime on 2026-06-16; checkout@v4 runs on the deprecated Node 20. checkout v6.0.2 declares runs.using: node24. All 9 usages (5 in build.yml, 4 in release.yml) are bare checkouts with no inputs, so the major bump is a drop-in. Still on Node-20-era majors in release.yml, deferred (multi-major jumps with breaking changes, and release.yml only runs on tag push): upload-artifact v4->v7, download-artifact v4->v8, softprops/action-gh-release v2->v3.	2026-06-01 11:40:05 -04:00
KaraZajac	35c33df16f	fragnesia: add 5.10.257 kernel_range entry (Debian bullseye backport) ... Weekly drift-check (build.yml schedule cron) went red 2026-06-01: Debian's security tracker now lists CVE-2026-46300 as fixed on the 5.10 branch (bullseye 5.10.257), a branch fragnesia's kernel_patched_from table didn't model. detect() would false-positive VULNERABLE on a patched bullseye 5.10.257+ host. Adding {5,10,257} clears the only MISSING finding; refresh-kernel-ranges.py now exits 0. The 10 remaining drifted modules are INFO-only 'more permissive' entries the check tolerates.	2026-06-01 11:05:05 -04:00
KaraZajac	25c2afc3e9	release v0.9.6: --auto no longer prompts for sudo password ... sudo_runas_neg1 and sudoedit_editor's detect() bodies invoked 'sudo -ln' (intending list + non-interactive). Some sudoers / PAM configurations have been observed prompting for a password anyway when the flags are bundled. That meant skeletonkey --auto --i-know could hang on a sudo password prompt during the corpus scan — bad ergonomics for an LPE tool whose whole point is to get root without already having it. Fix: write '-n -l' as separate flags, redirect stdin from /dev/null so sudo cannot fall back to reading the tty even if PAM tries to coerce one. Belt-and-suspenders against any tty prompt during --auto. v0.9.6	2026-05-28 21:50:26 -04:00
KaraZajac	13fbbce618	release v0.9.5: kernel_range drift cleanup (12 modules) ... v0.9.4 fixed cve_metadata drift but exposed kernel_range drift which had been hidden behind it. Applied refresh-kernel-ranges.py --patch recommendations: 11 TOO_TIGHT findings (false-positive risk — our threshold later than Debian's earliest known fix) + 8 MISSING (Debian has fixes for branches we didn't model) across 12 modules. All changes are strictly correctness-improving: detect() now correctly returns OK on kernels Debian has on record as patched, instead of false-positiving VULNERABLE. The biggest single fix is reverting fragnesia from {7,0,10} (NVD) to {7,0,9} (Debian's backported fix). I introduced that off-by-one in v0.9.4 from misreading NVD's versionEndExcluding semantics. Build's kernel_range drift step now exits 0 with 0 TOO_TIGHT + 0 MISSING. v0.9.5	2026-05-28 14:51:15 -04:00
KaraZajac	bb5ca48fe1	ci: enable workflow_dispatch on build workflow ... The drift-check job's if-gate already honors workflow_dispatch but the trigger itself was never added to the on: block. Without it, 'gh workflow run build.yml' fails with 422. Found while validating the v0.9.4 drift fix — wanted to confirm drift-check now passes without waiting for next Monday's cron.	2026-05-28 13:37:35 -04:00
KaraZajac	4454d8148e	release v0.9.4: drift unblock, fragnesia range fix, infra docs ... - Sync docs/CVE_METADATA.json + KEV_CROSSREF.md to match the hand-applied core/cve_metadata.c entries from v0.9.3. Nightly drift-check (red since 2026-05-25) now passes. Pintheft's CWE landed as CWE-787 from NVD (was NULL in the hand-applied entry). - Fix fragnesia (CVE-2026-46300) range table. Per NVD: bug entered at 5.11 SKBFL_SHARED_FRAG, vulnerable through 5.15.207 / 6.1.173 / 6.6.140 / 6.12.90 / 6.18.32 / 7.0.9, fixed at .208/.174/.141/ .91/.33/.10. Prior table had one entry {7,0,9} — off-by-one and missing every other backport. Added predates-5.11 introduction gate + test row. - Update tools/verify-vm/README.md to document the v0.9.x infra: mainline kernel pinning via kernel.ubuntu.com, per-module provisioner hooks, two-phase prep→reboot→verify with post-reboot kernel confirmation, GRUB_DEFAULT pinning. - Add curl fallback for NVD lookups in refresh-cve-metadata.py. Mirrors the CISA path's existing fallback. Prevents the silent Python urlopen hang seen during v0.9.3 prep (55-min stuck on CLOSE_WAIT socket; 30s timeout never fired). v0.9.4	2026-05-28 13:33:28 -04:00
KaraZajac	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). v0.9.3	2026-05-24 01:17:58 -04:00
KaraZajac	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
KaraZajac	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. v0.9.2	2026-05-24 00:03:35 -04:00
KaraZajac	92396a0d6d	tests: fix 2 test rows with wrong expected verdicts (v0.9.0 regression) ... The build workflow (sanitizer job) has been red since v0.9.0 because two test rows asserted verdicts that don't match what detect() actually returns: - udisks_libblockdev: I expected PRECOND_FAIL (udisksd absent in CI), got VULNERABLE. GHA ubuntu-24.04 runners ship udisks2 by default; detect() does direct path_exists() stat() calls (not host-fixture lookups) so it sees the binary and gates pass. Rewritten as 'udisksd present → VULNERABLE'. - sudo_runas_neg1: I expected PRECOND_FAIL (no (ALL,!root) grant), got OK. detect() treats 'no grant' as 'not exploitable from this user' → OK, not 'missing precondition' → PRECOND_FAIL. Updated expectation. The release workflow doesn't run the sanitizer job and has been passing through these failures; the build workflow caught them. Both expectations are now honest about what detect() does on CI.	2026-05-23 23:38:55 -04:00
KaraZajac	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. v0.9.1	2026-05-23 23:35:02 -04:00
KaraZajac	270ddc1681	verify-vm: per-module provisioner hook + old-mainline URL fallback ... Adds tools/verify-vm/provisioners/<module>.sh hook so per-module setup (build vulnerable sudo from source, drop polkit allow rule, add sudoers grant) lives in checked-in scripts rather than manual VM steps. Vagrantfile runs the script as root before build-and-verify if it exists. Also fixes mainline kernel fetch to fall back from /v${KVER}/amd64/ to /v${KVER}/ for old kernels (≤ ~4.15) where debs aren't under the amd64 subdir, and accepts both 'linux-image-' (old) and 'linux-image-unsigned-' (new) deb names. Wires up 4 previously-deferred targets to expect VULNERABLE: - sudo_chwoot: builds sudo 1.9.16p1 from upstream into /usr/local - udisks_libblockdev: installs udisks2 + polkit rule for vagrant user - mutagen_astronomy: pins mainline 4.14.70 (one below the .71 fix) - sudo_runas_neg1: adds (ALL,!root) sudoers grant	2026-05-23 22:36:02 -04:00
KaraZajac	7f4a6e1c7c	pintheft: drop --full-chain stub (calls undefined finisher symbol) ... The x86_64 path called finisher_modprobe_path_overwrite() which doesn't exist — the real API is skeletonkey_finisher_modprobe_path() with a callback signature. arm64 builds dodged it via the #if guard; x86_64 linker rightly choked. Same fix as tioscpgrp/vsock_uaf/nft_pipapo: primitive-only modules return EXPLOIT_FAIL honestly per verified-vs- claimed. v0.9.0	2026-05-23 22:22:31 -04:00
KaraZajac	f41eed834e	pintheft: add missing <sys/mman.h> for mmap/mprotect/PROT_* ... v0.9.0 release builds all 4 failed because pintheft module used mmap/ mprotect/PROT_READ/MAP_PRIVATE without including sys/mman.h. Worked on the dev host because some indirect include pulled it in; CI's stricter glibc/musl headers don't.	2026-05-23 22:19:59 -04:00
KaraZajac	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
KaraZajac	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
KaraZajac	c12ee6055c	release.yml: arm64-static via dockcross/linux-arm64-musl ... Third attempt at arm64-static. Previous two: 1. Alpine container on ubuntu-24.04-arm: 'JavaScript Actions in Alpine containers only supported on x64 Linux runners' — actions/checkout JS bundle can't run. 2. musl-tools on ubuntu-24.04-arm: musl-gcc + Ubuntu's /usr/include collide. -isystem /usr/include pulls glibc stdio.h whose __gnuc_va_list + __time64_t types conflict with musl's stdio.h. -isystem /usr/include/linux alone leaves us missing asm/ headers. dockcross/linux-arm64-musl avoids both: - Image base is Debian (glibc) → actions/checkout works. - Ships aarch64-linux-musl-gcc with a CONSISTENT musl + linux- uapi sysroot. No header collision. The dockcross pattern is: pull the image, ask it to spit out its wrapper script ('docker run --rm dockcross/linux-arm64-musl' prints a bash wrapper to stdout), then './dockcross bash -c ...' runs the command inside the toolchain container with the cwd volume-mounted. Produces a statically-linked aarch64 ELF binary, same packaging flow as the x86_64-static job. v0.7.1	2026-05-23 21:17:03 -04:00
KaraZajac	3e9f373751	release.yml: arm64-static — give musl-gcc access to Linux uapi headers ... Previous attempt failed with: modules/copy_fail_family/src/apparmor_bypass.c:23:10: fatal error: linux/capability.h: No such file or directory musl-gcc points at musl's libc headers, which (correctly) don't include Linux kernel uapi (linux/netfilter/*.h, linux/capability.h, etc.). On Ubuntu these come from the linux-libc-dev package living at /usr/include + /usr/include/aarch64-linux-gnu. Fix: -isystem both paths so musl-gcc can find Linux uapi without those paths shadowing musl's own libc decls (which they would if we used a plain -I). The Alpine x86_64 build doesn't hit this because Alpine's linux-headers package installs into musl's own include path.	2026-05-23 21:15:01 -04:00
KaraZajac	24c2821ae2	release.yml: arm64-static via musl-tools on ubuntu-24.04-arm (not Alpine) ... The v0.7.1 arm64-static build failed with: 'JavaScript Actions in Alpine containers are only supported on x64 Linux runners. Detected Linux Arm64' actions/checkout (and most other GitHub Actions) ship as Node.js bundles. On x86_64, GitHub's runner injects a glibc-compatible Node into Alpine containers; on arm64, that injection isn't available. The container fails to even check out the repo. Fix: run the arm64 static build natively on ubuntu-24.04-arm (a glibc-based runner that actions/checkout works on out of the box), and use Ubuntu's musl-tools package to get musl-gcc + musl-dev for the static link. The produced binary is still statically-linked against musl — just built outside an Alpine container. Refactor: the previous build-static matrix becomes two distinct jobs (build-static-x86_64 still Alpine-on-x64; build-static-arm64 now musl-tools-on-arm64). The release job's needs[] list and the artifact list are unchanged at the consumer level — the same four binaries (x86_64 dyn + static, arm64 dyn + static) plus install.sh still get published.	2026-05-23 21:13:06 -04:00
KaraZajac	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
KaraZajac	18fa3025f2	ci: silence Annex K noise from clang-tidy ... The first clang-tidy run on v0.7.0 reported 193 warnings, all from one check: clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling. That check flags snprintf, fprintf, memset, strncpy etc. and recommends the C11 Annex K _s variants (snprintf_s, memset_s, ...). Annex K is fundamentally not portable — glibc, musl, and MSVC all either don't implement it or implement it incompletely. snprintf is already bounds-checked via its size argument; this check is noise rather than signal in any real C codebase. Also pre-emptively disabling bugprone-easily-swappable-parameters which fires on every small utility function taking 2+ same-typed params (e.g. skeletonkey_host_kernel_at_least(host, major, minor, patch)). Everything else stays on. The next CI run will show whatever real findings hid under the noise.	2026-05-23 20:58:03 -04:00
KaraZajac	5b79b23ff2	ci: ASan/UBSan + clang-tidy lint + weekly drift check ... Three new jobs in build.yml: 1. sanitizers (clang + ASan/UBSan) Runs the same 88-test suite under AddressSanitizer + UndefinedBehaviorSanitizer. -fno-sanitize-recover=all so any finding fails CI loudly rather than scrolling past. -O1 + frame- pointers preserved for usable backtraces. CC=clang because clang's sanitizer integration is more mature than gcc's; gcc-built binaries still get exercised by the matrix in the main 'build' job. 2. clang-tidy (advisory) Lints core/ + skeletonkey.c (the files we control most directly; module sources often bundle published PoC code we keep close to upstream style, so they're excluded). continue-on-error: true for now so it sets a baseline without blocking merges; we can tighten incrementally as the warning surface shrinks. 3. drift-check (cron + workflow_dispatch) Runs weekly (Mon 06:00 UTC) and on-demand. Two sub-steps: - tools/refresh-cve-metadata.py --check (CISA KEV + NVD CWE) - tools/refresh-kernel-ranges.py (Debian security tracker) Both already exit non-zero on actionable drift. Network-required, so NOT gated on regular PR runs — random PRs shouldn't fail because CISA published a new KEV entry. The job runs ONLY on schedule + manual trigger (if: github.event_name == 'schedule' || ...). When it fires, the GH Actions warning annotation points the maintainer at the right refresh script to rerun + commit. Smoke-tested locally: - macOS local ASan+UBSan build: kernel_range tests pass; detect() tests skipped (non-Linux platform stubs). - clang-tidy not installed locally; CI installs from apt.	2026-05-23 20:46:27 -04:00
KaraZajac	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. v0.7.0	2026-05-23 20:44:45 -04:00
KaraZajac	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
KaraZajac	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
KaraZajac	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
KaraZajac	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
KaraZajac	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
KaraZajac	f792a3c4a6	verify-vm: close the loop — first successful end-to-end VM verification ... Five fixes that landed us at a working 'verify.sh <module> -> JSON verification record' loop. Tested with pwnkit on generic/ubuntu2004 / Ubuntu 20.04.6 LTS / 5.4.0-169-generic. 1. core/nft_compat.h — shim header that conditionally defines newer- kernel nft uapi constants that aren't in older distro headers: NFT_CHAIN_HW_OFFLOAD kernel 5.5 NFT_CHAIN_BINDING kernel 5.9 NFTA_VERDICT_CHAIN_ID kernel 5.14 NFTA_SET_DESC_CONCAT kernel 5.6 NFTA_SET_EXPR kernel 5.12 NFTA_SET_EXPRESSIONS kernel 5.16 NFTA_SET_ELEM_KEY_END kernel 5.6 NFTA_SET_ELEM_EXPRESSIONS kernel 5.16 Numeric values are stable kernel ABI; the target vulnerable kernel understands them at runtime regardless of the build host's headers. Without this, nf_tables / nft_fwd_dup / nft_payload / nft_set_uaf modules fail to compile on Ubuntu 20.04's libc-dev (5.4 uapi). 2. modules/{nf_tables, nft_fwd_dup, nft_payload, nft_set_uaf}/ skeletonkey_modules.c — each #includes the new compat shim after <linux/netfilter/nf_tables.h>. 3. tools/verify-vm/Vagrantfile — wrap config in 'c.vm.define host do |m| ... end' block so 'vagrant up <skk-MODULE>' finds the machine. (Earlier without define block, vagrant always treated the Vagrantfile as a single anonymous machine.) Also disable Parallels Tools auto- install — it fails on Ubuntu 20.04's 5.4 kernel ('current Linux kernel version is outdated and not supported by latest tools'); we use rsync sync_folder over plain SSH which doesn't need the tools. 4. tools/verify-vm/verify.sh — explicit 'vagrant rsync' before 'vagrant provision build-and-verify' so the source tree gets synced even on already-running VMs (vagrant up runs rsync automatically; vagrant provision does not). 5. tools/verify-vm/verify.sh — fix verdict parser. Vagrant prefixes provisioner stdout with the VM name (' skk-pwnkit: VERDICT: VULNERABLE'), so the previous '^VERDICT: ' regex never matched. New grep allows the prefix; added '|| true' so a grep miss doesn't trigger set-e+pipefail and silently exit the script before the JSON verification record gets emitted. First successful verification record: { "module": "pwnkit", "verified_at": "2026-05-23T19:26:02Z", "host_kernel": "5.4.0-169-generic", "host_distro": "Ubuntu 20.04.6 LTS", "vm_box": "generic/ubuntu2004", "expect_detect": "VULNERABLE", "actual_detect": "VULNERABLE", "status": "match" } SKELETONKEY correctly identifies polkit 0.105 on Ubuntu 20.04 as vulnerable to CVE-2021-4034. The verifier pipeline is now ready for sweep across the rest of the corpus.	2026-05-23 15:26:51 -04:00
KaraZajac	2c4cde1031	verify-vm: fix Vagrantfile for first real run ... Two issues surfaced during the first end-to-end verification attempt (verify.sh pwnkit, generic/ubuntu2004): 1. 'The machine with the name skk-pwnkit was not found' — the original Vagrantfile used c.vm.box/hostname without a c.vm.define block, so passing a machine name to 'vagrant up <name>' had nothing to match. Wrap every per-machine config in 'c.vm.define host do |m| ... end' so each module gets its own tracked machine in .vagrant/machines/skk-<module>/parallels/. 2. 'Installing the proper version of Parallels Tools' fails on Ubuntu 20.04: 'Error: current Linux kernel version 5.4.0-169-generic is outdated and not supported'. The latest Parallels Tools wants newer guest kernels. We don't need the Tools at all — rsync sync_folder over plain SSH does our source mount. Disable both: p.update_guest_tools = false p.check_guest_tools = false Verified externally (with Apple hypervisor as a temporary bypass during the user's pending Parallels-extension allow + Mac restart): the VM boots, SSH connects, network works. The only remaining gate was the Parallels Tools provisioner now skipped.	2026-05-23 14:59:10 -04:00
KaraZajac	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
KaraZajac	554a58757e	tools/verify-vm: turnkey Vagrant + Parallels verification scaffolding ... Closes the gap between 'detect() compiles and passes unit tests' and 'exploit() actually works on a real vulnerable kernel'. One-time setup + one command per module to verify against a known-vulnerable guest, with results emitted as JSON verification records. Files: setup.sh — one-shot bootstrap. Installs Vagrant via brew if missing, installs vagrant-parallels plugin, pre- downloads 5 base boxes (~5 GB): generic/ubuntu1804 (4.15.0) generic/ubuntu2004 (5.4.0 + HWE) generic/ubuntu2204 (5.15.0 + HWE) generic/debian11 (5.10.0) generic/debian12 (6.1.0) Idempotent; can pass --boxes subset. Vagrantfile — single parameterized config driven by SKK_VM_* env vars. Provisioners: build-deps install, kernel pin (apt + snapshot.debian.org fallback), build-and-verify (kept run='never' so verify.sh invokes explicitly after reboot if pin'd). targets.yaml — module → (box, kernel_pkg, kernel_version, expect_detect, notes) mapping for all 26 modules. 3 marked manual: true (vmwgfx needs VMware guest; dirtydecrypt + fragnesia need Linux 7.0 not yet shipping as distro kernel). verify.sh — entrypoint. 'verify.sh <module>' provisions if needed, pins kernel + reboots if needed, runs 'skeletonkey --explain --active' inside the VM, parses VERDICT, compares to expect_detect, emits JSON verification record. --list shows the full target matrix. --keep / --destroy lifecycle flags. README.md — workflow + extending the targets table. Design notes: - Pure bash + awk targets.yaml parsing — no PyYAML dep (macOS Python is PEP-668 'externally managed' and refuses pip --user installs). - Sources of vulnerable kernel packages: stock distro kernels where they're below the fix backport, otherwise pinned via apt with snapshot.debian.org as last-resort fallback (the Debian apt snapshot archive is the canonical source for historical kernel .deb packages). - Repo mounted at /vagrant via rsync (not 9p — vagrant-parallels' 9p is finicky on macOS Sequoia per the plugin issue tracker). - VM lifecycle defaults to suspend-after-verify so the next run resumes in ~5s instead of cold-booting. - kernel pin reboots are handled by checking 'uname -r' after the pin provisioner and triggering 'vagrant reload' if mismatched. Verification records (JSON on stdout per run) are intended to feed a per-module verified_on[] table in a follow-up commit — that's the 'permanent trust artifact' angle from the earlier roadmap discussion. Smoke tests (no VM actually spun up): - 'verify.sh --list': renders the 26-module matrix correctly. - 'verify.sh nf_tables': dispatches to generic/ubuntu2204 + kernel 5.15.0-43 + expect=VULNERABLE; fails cleanly at 'vagrant: command not found' (expected — user runs setup.sh first). - 'verify.sh vmwgfx': errors with 'is marked manual: true' + note. .gitignore: tools/verify-vm/{logs,.vagrant}/ excluded. Usage: ./tools/verify-vm/setup.sh # one time, ~5 min ./tools/verify-vm/verify.sh nf_tables # ~5 min first run, ~1 min after ./tools/verify-vm/verify.sh --list # show all targets	2026-05-23 11:19:28 -04:00
KaraZajac	8ab49f36f6	detection rules: complete sigma/yara/falco coverage across the corpus ... Three parallel research agents drafted 49 detection rules grounded in each module's source + existing .opsec_notes string + existing .detect_auditd counterpart. A one-shot tools/inject_rules.py wrote them into the right files and replaced the .detect_<format> = NULL placeholders. Coverage matrix (modules with each format / 31 total): before after auditd 30 / 31 30 / 31 (entrybleed skipped by design) sigma 19 / 31 31 / 31 (+12 added) yara 11 / 31 28 / 31 (+17 added; 3 documented skips) falco 11 / 31 30 / 31 (+19 added; entrybleed skipped) Documented skips (kept as .detect_<format> = NULL with comment): - entrybleed: yara + falco + auditd. Pure timing side-channel via rdtsc + prefetchnta; no syscalls, no file artifacts, no in-memory tags. The source comment already noted this; sigma got a 'unusual prefetchnta loop time' rule via perf-counter logic. - ptrace_traceme: yara. Pure in-memory race; no on-disk artifacts or persistent strings to match. Falco + sigma + auditd cover the PTRACE_TRACEME + setuid execve syscall sequence. - sudo_samedit: yara. Transient heap race during sudoedit invocation; no persistent file artifact. Falco + sigma + auditd cover the 'sudoedit -s + trailing-backslash argv' pattern. Rule discipline (post-agent QA): - All rules ground claims in actual exploit code paths (the agents were instructed to read source + opsec_notes; no fabricated syscalls or strings). - Two falco rules were narrowed by the agent to fire only when proc.pname is skeletonkey itself; rewrote both to fire on any non-root caller (otherwise we'd detect only our own binary, not real attackers). - Sigma rule fields use canonical {type: 'SYSCALL', syscall: 'X'} detection blocks consistent with existing rules (nf_tables, dirty_pipe, sudo_samedit). - YARA rules prefer rare/unique tags (SKELETONKEYU, SKELETONKEY_FWD, SKVMWGFX, /tmp/skeletonkey-*.log) over common bytes — minimizes false positives. - Every rule tagged with attack.privilege_escalation + cve.YYYY.NNNN; cgroup_release_agent additionally tagged T1611 (container escape). skeletonkey.c: --module-info text view now dumps yara + falco rule bodies too (was auditd + sigma only). All 4 formats visible per module. Verification: - macOS local: clean build, 33 kernel_range tests pass. - Linux (docker gcc:latest): 33 + 54 = 87 passes, 0 fails. - --module-info nf_tables / af_unix_gc / etc.: 'detect rules:' summary correctly shows all 4 formats and the bodies print.	2026-05-23 11:10:54 -04:00
KaraZajac	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
KaraZajac	39ce4dff09	modules: per-module OPSEC notes — telemetry footprint per exploit ... Adds .opsec_notes to every module's struct skeletonkey_module (31 entries across 26 module files). One paragraph per exploit describing the runtime footprint a defender/SOC would see: - file artifacts created/modified (exact paths from source) - syscall observables (the unshare / socket / setsockopt / splice / msgsnd patterns the embedded detection rules look for) - dmesg signatures (silent on success vs KASAN oops on miss) - network activity (loopback-only vs none) - persistence side-effects (/etc/passwd modification, dropped setuid binaries, backdoors) - cleanup behaviour (callback present? what it restores?) Each note is grounded in the module's source code + its existing auditd/sigma/yara/falco detection rules — the OPSEC notes are literally the inverse of those rules (the rules describe what to look for; the notes describe what the exploit triggers). Three intelligence agents researched the modules in parallel, reading source + MODULE.md, then their proposals were embedded verbatim via tools/inject_opsec.py (one-shot script, not retained). Where surfaced: - --module-info <name>: '--- opsec notes ---' section between detect-rules summary and the embedded auditd/sigma rule bodies. - --module-info / --scan --json: 'opsec_notes' top-level string. Audience uses: - Red team: see what footprint each exploit leaves so they pick chains that match the host's telemetry posture. - Blue team: the notes mirror the existing detection rules from the attacker side — easy diff to find gaps in their SIEM coverage. - Researchers: per-exploit footprint catalog for technique analysis. copy_fail_family gets one shared note across all 5 register entries (copy_fail, copy_fail_gcm, dirty_frag_esp, dirty_frag_esp6, dirty_frag_rxrpc) since they share exploit infrastructure. Verification: - macOS local: clean build, --module-info nf_tables shows full opsec section + CWE + ATT&CK + KEV row from previous commit. - Linux (docker gcc:latest): 33 + 54 = 87 passes, 0 fails. Next: --explain mode (uses these notes + the triage metadata to render a single 'why is this verdict, what would patch fix it, and what would the SOC see' page per module).	2026-05-23 10:45:38 -04:00