v0.9.0
12 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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. |
||
|
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. |
||
|
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.
|
||
|
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.
|
||
|
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.
|
||
|
leviathan
|
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.
|
||
|
leviathan
|
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.
|
||
|
leviathan
|
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
|
||
|
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.
|
||
|
leviathan
|
df4b879527 |
tools: refresh-kernel-ranges.py — Debian tracker drift detection
Standalone Python script that pulls Debian's security-tracker JSON
and compares each module's hardcoded kernel_patched_from table
against the fixed-versions Debian actually ships. Surfaces real
drift the no-fabrication rule needs us to fix:
MISSING — Debian has a fix on a kernel branch we have no entry
for. Module's detect() would say VULNERABLE on a host
that's actually patched.
TOO_TIGHT — Our threshold is later than Debian's earliest fix on
the same branch. Module would call a patched host
VULNERABLE. False-positive on production fleets.
INFO — Our threshold is earlier than Debian's. We're more
permissive; usually fine (we tracked a different
upstream-stable cut), but flagged for review.
Three output modes:
default (text) — human-readable report on stderr
--json — machine-readable for CI / dashboards
--patch — unified-diff-style proposed C-source edits
--refresh — bypass the 12h cache TTL and re-fetch
Implementation:
- urllib (no pip deps) fetches the ~70MB tracker JSON.
- Cached at /tmp/skeletonkey-debian-tracker.json with 12h TTL.
- Parses every modules/*/skeletonkey_modules.c for the .cve = '...'
field + the kernel_patched_from <name>[] = { {M,m,p}, ... } array.
- Per CVE, builds {debian_release -> upstream_version_tuple} from
the tracker's 'releases.*.fixed_version' field (stripping Debian
-N / +bN / ~bpoN suffixes to recover the upstream version).
- Groups by (major, minor) branch; flags MISSING / TOO_TIGHT / INFO.
- Exits non-zero when MISSING or TOO_TIGHT findings exist (suitable
for a CI 'detect-drift' job).
First-run output found drift in 17 of 20 modules with kernel_range
tables — operator-reviewable. NOT auto-applied; this commit only
ships the diagnostic tool, not the suggested fixes.
README's Contributing section now points at the tool.
|
||
|
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.
|
||
|
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 |