f792a3c4a6f4977639b26db7d3eaccd376b1e922
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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
|
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.
|
||
|
leviathan
|
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).
|
||
|
leviathan
|
8de46e212e |
kernel_range: refresh tables from Debian tracker — 5 MISSING adds + 4 off-by-one harmonisations
First batch of fixes surfaced by tools/refresh-kernel-ranges.py.
Drift drops from 18 actionable findings (5 MISSING + 13 TOO_TIGHT)
to 13 (now only 1 MISSING + 12 TOO_TIGHT). The remaining
TOO_TIGHT findings all involve threshold-version drops of 2+
patch versions; those need per-commit verification against
git.kernel.org/linus before applying (saving for a follow-up).
MISSING adds — branches Debian has fixed that we had no entry for:
af_unix_gc (CVE-2023-4622):
+ {6, 4, 13} stable 6.4.x (forky/sid/trixie all at this version)
dirtydecrypt (CVE-2026-31635):
+ {6, 19, 13} stable 6.19.x (forky/sid) — our previous table
only listed mainline 7.0.0; Debian is shipping
the fix on the 6.19 branch ahead of 7.0 release.
overlayfs_setuid (CVE-2023-0386):
+ {5, 10, 179} stable 5.10.x (bullseye)
vmwgfx (CVE-2023-2008):
+ {5, 10, 127} stable 5.10.x (bullseye)
+ {5, 18, 14} stable 5.18.x (bookworm/forky/sid/trixie)
TOO_TIGHT harmonisations — single-patch-version differences,
almost certainly off-by-one curation errors on our side:
nf_tables (CVE-2024-1086):
{5, 10, 210} -> {5, 10, 209} (Debian bullseye)
nft_payload (CVE-2023-0179):
{5, 10, 163} -> {5, 10, 162} (Debian bullseye)
nft_set_uaf (CVE-2023-32233):
{5, 10, 180} -> {5, 10, 179} (Debian bullseye)
{6, 1, 28} -> {6, 1, 27} (Debian bookworm)
Larger TOO_TIGHT diffs deferred:
- cgroup_release_agent (5.16.9 -> 5.16.7, diff 2)
- cls_route4 (5.18.18 -> 5.18.16, diff 2; 5.10.143 -> 5.10.136, diff 7)
- dirty_cow (4.7.10 -> 4.7.8, diff 2)
- dirty_pipe (5.10.102 -> 5.10.92, diff 10)
- netfilter_xtcompat (5.10.46 -> 5.10.38, diff 8)
- overlayfs_setuid (6.1.27 -> 6.1.11, diff 16)
- ptrace_traceme (4.19.58 -> 4.19.37, diff 21)
- sequoia (5.10.52 -> 5.10.46, diff 6)
These need per-commit confirmation against the upstream-stable
kernel changelog before lowering our threshold. Conservatively
keeping the current (more strict) values until each is verified.
Verification:
- Linux (docker gcc:latest + libglib2.0-dev + sudo): 44/44 tests
pass, full build clean.
- macOS (local): 31-module build clean.
- tools/refresh-kernel-ranges.py rerun: drift reduced 18 -> 13.
|
||
|
leviathan
|
2b1e96336e |
core/host: in_range helper + 13-module migration + 12 more tests (29 total)
Three coordinated changes that build on the host_kernel_at_least
landed in
|
||
|
leviathan
|
36814f272d |
modules: migrate remaining 22 modules to ctx->host fingerprint
Completes the host-fingerprint refactor that started in
|
||
|
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.
|