5d48a7b0b55faf254f7826c84d4f9c6a5e7bcf84
11 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 leviathan
|
5d48a7b0b5 |
release v0.7.1: arm64-static binary + per-module arch_support
Two additions on top of v0.7.0:
1. skeletonkey-arm64-static is now published alongside the existing
x86_64-static binary. Built native-arm64 in Alpine via GitHub's
ubuntu-24.04-arm runner pool (free for public repos as of 2024).
install.sh auto-picks it based on 'uname -m'; SKELETONKEY_DYNAMIC=1
fetches the dynamic build instead. Works on Raspberry Pi 4+, Apple
Silicon Linux VMs, AWS Graviton, Oracle Ampere, Hetzner ARM, etc.
.github/workflows/release.yml refactor: the previous single
build-static-x86_64 job becomes a build-static matrix with two
entries (x86_64-static on ubuntu-latest, arm64-static on
ubuntu-24.04-arm). Both share the same Alpine container + build
recipe.
2. .arch_support field on struct skeletonkey_module — honest per-module
labeling of which architectures the exploit() body has been verified
on. Three categories:
'any' (4 modules): pwnkit, sudo_samedit, sudoedit_editor,
pack2theroot. Purely userspace; arch-independent.
'x86_64' (1 module): entrybleed. KPTI prefetchnta side-channel;
x86-only by physics. Already source-gated (returns
PRECOND_FAIL on non-x86_64).
'x86_64+unverified-arm64' (26 modules): kernel exploitation
code. The bug class is generic but the exploit primitives
(msg_msg sprays, finisher chain, struct offsets) haven't been
confirmed on arm64. detect() still works (just reads ctx->host);
only the --exploit path is in question.
--list now has an ARCH column (any / x64 / x64?) and the footer
prints 'N arch-independent (any)'.
--module-info prints 'arch support: <value>'.
--scan --json adds 'arch_support' to each module record.
This is the honest 'arm64 works for detection on every module +
exploitation on 4 of them today; the rest await empirical arm64
sweep' framing — not pretending the kernel exploits already work
there, but not blocking the arm64 binary on that either. arm64
users get the full triage workflow + a handful of userspace exploits
out of the box, plus a clear roadmap for the rest.
Future work to promote modules from 'x86_64+unverified-arm64' to
'any': add an arm64 Vagrant box (generic/debian12-arm64 etc.) to
tools/verify-vm/ and run a verification sweep on Apple Silicon /
ARM Linux hardware.
|
||
|
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.
|
||
|
leviathan
|
9d88b475c1 |
v0.3.1: --dump-offsets tool + NOTICE.md per module
The README has been claiming "each module credits the original CVE
reporter and PoC author in its NOTICE.md" since v0.1.0, but only
copy_fail_family actually shipped one. Fixed.
modules/<name>/NOTICE.md (×19 new + 1 existing): per-module
research credit covering CVE ID, discoverer, original advisory
URL where public, upstream fix commit, IAMROOT's role.
iamroot.c: new --dump-offsets subcommand. Resolves kernel offsets
via the existing core/offsets.c four-source chain (env →
/proc/kallsyms → /boot/System.map → embedded table), then emits
a ready-to-paste C struct entry for kernel_table[]. Run once
as root on a target kernel build; upstream via PR. Eliminates
fabricating offsets — every shipped entry traces back to a
`iamroot --dump-offsets` invocation on a real kernel.
docs/OFFSETS.md: documents the --dump-offsets workflow.
CVES.md: notes the NOTICE.md convention + offset dump tool.
iamroot.c: bump IAMROOT_VERSION 0.3.0 → 0.3.1.
|
||
|
leviathan
|
5a808e3583 |
modules: 4 new CVE modules — nft_set_uaf + af_unix_gc + nft_fwd_dup + nft_payload
Each module: detect with branch-backport ranges + userns reach +
hand-rolled trigger + msg_msg cross-cache groom + slabinfo witness
+ /tmp/iamroot-<name>.log breadcrumb + auditd rules + --full-chain
finisher (FALLBACK depth, sentinel-arbitrated).
nft_set_uaf (CVE-2023-32233, +1033): anonymous-set UAF
(Sondej+Krysiuk). 5.1 → 6.4. nfnetlink batch:
NEWTABLE → NEWCHAIN → NEWSET(ANON|EVAL) →
NEWRULE(lookup) → DELSET → DELRULE; cg-512 spray.
af_unix_gc (CVE-2023-4622, +813): GC race UAF (Lin Ma). ~2.0 → 6.5
— widest range of any module. Two-thread race driver
(SCM_RIGHTS cycle vs unix_gc trigger) + kmalloc-512
spray. No userns needed.
nft_fwd_dup (CVE-2022-25636, +1024): nft_fwd_dup_netdev_offload
heap OOB (Aaron Adams). 5.4 → 5.17. NFT_CHAIN_HW_OFFLOAD
chain + 16 immediates + fwd to overrun action.entries[].
nft_payload (CVE-2023-0179, +1136): set-id memory corruption
(Davide Ornaghi). 5.4 → 6.2. NFTA_SET_DESC variable
element + NFTA_SET_ELEM_EXPRESSIONS with payload-set
whose verdict.code drives the regs->data[] OOB.
All 4 honor verified-vs-claimed: trigger fires, primitive grooms, no
fabricated offsets. EXPLOIT_OK only via empirical setuid-bash sentinel.
Build clean on Debian 6.12.86; all 4 refuse cleanly on both default
and --full-chain paths via the existing patched-kernel detect gate.
|
||
|
leviathan
|
6a0a7d8718 |
scaffold: 4 new module dirs + registry/Makefile wiring (stubs)
Pre-scaffolding for the next batch (CVE-2023-32233, CVE-2023-4622, CVE-2022-25636, CVE-2023-0179). Each module ships as a 21-line stub returning PRECOND_FAIL; parallel agents fill in the real detect/exploit/--full-chain implementations. This commit keeps registry.h / iamroot.c / Makefile in one place so the 4 parallel agents don't collide on shared-file edits — they each own a single iamroot_modules.c. Build clean on Debian 6.12.86; --list shows all 24 modules including the 4 new stubs. |