Commit Graph

20 Commits

Author SHA1 Message Date
leviathan 67d091dd37 verified_on table — 5 modules empirically confirmed in real VMs
Closes the loop opened by tools/verify-vm/: every JSON verification
record now persists into docs/VERIFICATIONS.jsonl, gets folded into
the embedded core/verifications.c lookup table, and surfaces in
--list / --module-info / --explain / --scan --json.

New: docs/VERIFICATIONS.jsonl
  Append-only store. One JSON record per verify.sh run. Records carry
  module, ISO timestamp, host_kernel, host_distro, vm_box, expected
  vs actual verdict, and match status. 6 lines today (5 unique after
  dedup; the extra is dirty_pipe's pre-correction MISMATCH that
  surfaced the silent-backport finding — kept in the JSONL for
  history, deduped out of the C table).

New: tools/refresh-verifications.py
  Parses VERIFICATIONS.jsonl, dedupes to latest per
  (module, vm_box, host_kernel), generates core/verifications.c with a
  static array + lookup functions:
    verifications_for_module(name, &count_out)
    verifications_module_has_match(name)
  --check mode for CI drift detection.

New: core/verifications.{h,c}
  Embedded record table. Lookup is O(corpus); we have <50 records.

skeletonkey.c surfacing:
  - --list: new 'VFY' column shows ✓ for modules with >=1 'match'
    record. Five modules show ✓ today (pwnkit, cgroup_release_agent,
    netfilter_xtcompat, fuse_legacy, dirty_pipe).
  - --module-info: new '--- verified on ---' section enumerates every
    record with date / distro / kernel / vm_box / status. Modules with
    zero records get a 'run tools/verify-vm/verify.sh <name>' hint.
  - --explain: new 'VERIFIED ON' section in the operator briefing.
  - --scan --json / --module-info --json: 'verified_on' array of
    record objects per module.

Verification records baked in:

  pwnkit               Ubuntu 20.04.6 LTS  5.4.0-169   match (polkit 0.105)
  cgroup_release_agent Debian 11 (bullseye) 5.10.0-27  match
  netfilter_xtcompat   Debian 11 (bullseye) 5.10.0-27  match
  fuse_legacy          Debian 11 (bullseye) 5.10.0-27  match
  dirty_pipe           Ubuntu 22.04.3 LTS   5.15.0-91  match (OK; silent backport)

The dirty_pipe record is particularly informative: stock Ubuntu 22.04
ships 5.15.0-91-generic. Our version-only kernel_range check would say
VULNERABLE (5.15.0 < 5.15.25 backport in our table). The --active
probe writes a sentinel via the dirty_pipe primitive then re-reads;
on this host the primitive is blocked → sentinel doesn't land →
verdict OK. Ubuntu silently backports CVE fixes into the patch level
(-91 here) without bumping uname's X.Y.Z. The targets.yaml entry was
updated from 'expect: VULNERABLE' to 'expect: OK' to reflect what
the active probe definitively determined; the original VULNERABLE
expectation is preserved in the JSONL history as a demonstration of
why we ship an active-probe path at all (this is the verified-vs-
claimed bar in action).

Plumbing fixes that landed in the same loop:

  - core/nft_compat.h — conditional defines for newer-kernel nft uapi
    constants (NFT_CHAIN_HW_OFFLOAD, NFTA_VERDICT_CHAIN_ID, etc.)
    that aren't in Ubuntu 20.04's pre-5.5 linux-libc-dev. Without
    this, nft_* modules failed to compile inside the verifier guest.
    Included from each nft module after <linux/netfilter/nf_tables.h>.

  - tools/verify-vm/Vagrantfile — wrap config in c.vm.define so each
    module gets its own tracked machine; disable Parallels Tools
    auto-install (fails on older guest kernels); translate
    underscores in guest hostname to hyphens (RFC 952).

  - tools/verify-vm/verify.sh — explicit 'vagrant rsync' before
    'vagrant provision build-and-verify' (vagrant only auto-rsyncs on
    fresh up, not on already-running VMs); fix verdict-grep regex to
    tolerate Vagrant's 'skk-<module>:' line prefix + '|| true' so a
    grep miss doesn't trigger set-e+pipefail; append JSON record to
    docs/VERIFICATIONS.jsonl on every run.

  - tools/verify-vm/targets.yaml — dirty_pipe retargeted from
    ubuntu2004 + pinned 5.13.0-19 (no longer in 20.04's apt) to
    ubuntu2204 stock 5.15.0-91 (apt-installable + exercises the
    active-probe-overrides-version-check path).

What's next for the verifier:
  - Mainline kernel.ubuntu.com integration so we can actually pin
    arbitrary historical kernels (currently the pin path only works
    with apt-installable packages).
  - Sweep the remaining ~18 verifiable modules and accumulate records.
  - Per-module verified_on counts in --explain header.
2026-05-23 15:46:14 -04:00
leviathan 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
leviathan ee3e7dd9a7 skeletonkey: --explain MODULE — single-page operator briefing
One command that answers 'should we worry about this CVE here,
what would patch it, and what would the SOC see if someone tried
it'. Renders, for the specified module:

  - Header: name + CVE + summary
  - WEAKNESS: CWE id and MITRE ATT&CK technique (from CVE metadata)
  - THREAT INTEL: CISA KEV status (with date_added if listed) and
    the upstream-curated kernel_range
  - HOST FINGERPRINT: kernel + arch + distro from ctx->host plus
    every relevant capability gate (userns / apparmor / selinux /
    lockdown)
  - DETECT() TRACE (live): runs the module's detect() with verbose
    stderr enabled so the operator sees the gates fire in real
    time — 'kernel X is patched', 'userns blocked by AppArmor',
    'no readable setuid binary', etc.
  - VERDICT: the result_t with a one-line operator interpretation
    that varies by outcome (OK / VULNERABLE / PRECOND_FAIL /
    TEST_ERROR each get their own framing)
  - OPSEC FOOTPRINT: word-wrapped .opsec_notes paragraph (from
    last commit) showing what an exploit would leave behind on
    this host
  - DETECTION COVERAGE: which of auditd/sigma/yara/falco have
    embedded rules for this module, with pointers to the
    --module-info / --detect-rules commands that dump the bodies

Targeted at every audience the project is meant to serve:
  - Red team: opsec footprint + 'would this even reach' verdict
    in one screen
  - Blue team: paste-ready triage ticket with CVE / CWE / ATT&CK /
    KEV header and detection-coverage matrix
  - Researchers: the live trace shows the reasoning chain
    (predates check, kernel_range_is_patched lookup, userns gate)
    that drove the verdict — auditable without reading source
  - SOC analysts / students: a single self-contained briefing per
    CVE, no cross-referencing needed

Implementation:
  - New mode MODE_EXPLAIN, new flag --explain MODULE
  - cmd_explain() composes the page from the existing module
    struct, cve_metadata_lookup() (federal-source triage data),
    ctx->host (cached fingerprint), and a live detect() call
  - print_wrapped() helper word-wraps the long .opsec_notes
    paragraph at 76 cols / 2-space indent
  - Help text + README quickstart + DETECTION_PLAYBOOK single-host
    recipe all updated to mention --explain

Smoke tests:
  - macOS: --explain nf_tables shows full briefing; trace says
    'Linux-only module — not applicable here'; verdict
    PRECOND_FAIL with the generic-precondition interpretation
  - Linux (docker gcc:latest): --explain nf_tables on a 6.12 host
    fires '[+] nf_tables: kernel 6.12.76-linuxkit is patched';
    verdict OK with the 'this host is patched' interpretation
  - Both: --explain nope (unknown module) returns 1 with a clear
    'no module ... Try --list' error
  - Both: 87 tests still pass (33 kernel_range + 54 detect on Linux,
    33 + 0 stubbed on macOS)

Closes the metadata + opsec + explain trio. The three together
answer the 'best tool for red team, blue team, researchers, and
more' framing.
2026-05-23 10:49:46 -04:00
leviathan e4a600fef2 module metadata: CWE + ATT&CK + CISA KEV triage from federal sources
Adds per-CVE triage annotations that turn SKELETONKEY's JSON output
into something a SIEM/CTI/threat-intel pipeline can route on, and a
KEV badge in --list so operators see at-a-glance which modules
cover actively-exploited bugs.

New tool — tools/refresh-cve-metadata.py:

  - Discovers CVEs by scanning modules/<dir>/ (no hardcoded list).
  - Fetches CISA's Known Exploited Vulnerabilities catalog
    (https://www.cisa.gov/.../known_exploited_vulnerabilities.csv).
  - Fetches CWE classifications from NVD's CVE API 2.0
    (services.nvd.nist.gov), throttled to the anonymous
    5-req/30s limit (~3 minutes for 26 CVEs).
  - Hand-curated ATT&CK technique mapping (T1068 default; T1611 for
    container escapes, T1082 for kernel info leaks — MITRE doesn't
    publish a clean CVE→technique feed).
  - Generates three outputs:
      docs/CVE_METADATA.json   machine-readable, drift-checkable
      docs/KEV_CROSSREF.md     human-readable table
      core/cve_metadata.c      auto-generated lookup table
  - --check mode diffs the committed JSON against a fresh fetch for
    CI drift detection.

New core API — core/cve_metadata.{h,c}:

  struct cve_metadata { cve, cwe, attack_technique, attack_subtechnique,
                        in_kev, kev_date_added };
  const struct cve_metadata *cve_metadata_lookup(const char *cve);

Lookup keyed by CVE id, not module name — the metadata is properties
of the CVE (two modules covering the same bug see the same metadata).
The opsec_notes field stays on the module struct because exploit
technique varies per-module (different footprints).

Output surfacing:
  - --list: new KEV column shows ★ for KEV-listed CVEs.
  - --module-info (text): prints cwe / att&ck / 'in CISA KEV: YES (added
    YYYY-MM-DD)' between summary and operations.
  - --module-info / --scan (JSON): emits a 'triage' subobject with the
    full record, plus an 'opsec_notes' field at top level when set.

Initial snapshot:
  - 10 of 26 modules cover KEV-listed CVEs (dirty_cow, dirty_pipe,
    pwnkit, sudo_samedit, ptrace_traceme, fuse_legacy, nf_tables,
    overlayfs, overlayfs_setuid, netfilter_xtcompat).
  - 24 of 26 have NVD CWE mappings; 2 unmapped (NVD has no weakness
    record for CVE-2019-13272 and CVE-2026-46300 yet).
  - All 26 mapped to an ATT&CK technique.

Verification:
  - macOS local: 33 kernel_range + clean build, --module-info shows
    'in CISA KEV: YES (added 2024-05-30)' for nf_tables, --list KEV
    column renders.
  - Linux (docker gcc:latest): 33 + 54 = 87 passes, 0 fails.

Follow-up commits will add per-module OPSEC notes and --explain mode.
2026-05-23 10:38:01 -04:00
leviathan 8243817f7e test harness: kernel_range unit tests + coverage report + register_all helper
Three coupled improvements to the test harness:

1. New tests/test_kernel_range.c — 32 pure unit tests covering
   kernel_range_is_patched(), skeletonkey_host_kernel_at_least(),
   and skeletonkey_host_kernel_in_range(). These are the central
   comparison primitives every module routes through; a regression
   in any of them silently mis-classifies entire CVE families. Tests
   cover exact boundary, one-below, mainline-only, multi-LTS,
   between-branch, and NULL-safety cases. Builds and runs
   cross-platform (no Linux syscalls).

2. tests/test_detect.c additions:
   - mk_host(base, major, minor, patch, release) builder so new
     fingerprint-based tests don't duplicate 14-line struct literals
     to override one (major, minor, patch) triple.
   - Post-run coverage report that iterates the runtime registry and
     warns about modules without at least one direct test row. Output
     is informational (no CI fail) so coverage grows incrementally.
   - 7 new boundary tests for the kernel_patched_from entries added
     by tools/refresh-kernel-ranges.py (commit 8de46e2):
       - af_unix_gc 6.4.12 → VULNERABLE / 6.4.13 → OK
       - vmwgfx 5.10.127 → OK
       - nft_set_uaf 5.10.179 → OK / 6.1.27 → OK
       - nft_payload 5.10.162 → OK
       - nf_tables 5.10.209 → OK

3. core/registry_all.c — extracts the 27-line 'call every
   skeletonkey_register_<family>()' enumeration from skeletonkey.c
   into a shared helper. skeletonkey.c main() now calls
   skeletonkey_register_all_modules() once; the detect-test main()
   does the same. Kept in its own translation unit so registry.c
   stays standalone for the lean kernel_range unit-test binary
   (which links core/ only, no modules).

Makefile: builds two test binaries now —
  skeletonkey-test     — detect() integration tests (full corpus)
  skeletonkey-test-kr  — kernel_range unit tests (core/ only)
'make test' runs both.

Verification:
  - macOS: 32/32 kernel_range tests pass; detect tests skipped
    (non-Linux platform, stubbed bodies).
  - Linux (docker gcc:latest): 32/32 kernel_range + 51/51 detect.
    Coverage report identifies 2 modules without direct tests
    (copy_fail, entrybleed) out of 31 registered.

Test counts: 44 -> 83 (+39).
2026-05-23 01:09:30 -04:00
leviathan 97be306fd2 release: bump version to v0.6.0
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
This release captures the session's reliability + accuracy work
on top of v0.5.0:

- Shared host fingerprint (core/host.{h,c}): kernel/distro/userns
  gates / sudo + polkit versions, populated once at startup; every
  module consults ctx->host instead of doing its own probes.
- Test harness (tests/test_detect.c, make test): 44 unit tests over
  mocked host fingerprints, wired into CI as a non-root step.
- --auto upgrades: auto-enables --active, per-detect 15s timeout,
  fork-isolated detect + exploit so a crashing module can't tear
  down the dispatcher, per-module verdict table + scan summary.
- --dry-run flag (preview without firing; --i-know not required).
- Pinned mainline fix commits for the 3 ported modules
  (dirtydecrypt / fragnesia / pack2theroot) — detect() is now
  version-pinned with kernel_range tables, not precondition-only.
- New modules: dirtydecrypt (CVE-2026-31635), fragnesia
  (CVE-2026-46300), pack2theroot (CVE-2026-41651).
- macOS dev build works for the first time (all Linux-only code
  wrapped in #ifdef __linux__).
- docs/JSON_SCHEMA.md: stable consumer contract for --scan --json.

Version bump:
- SKELETONKEY_VERSION = '0.6.0' in skeletonkey.c
- README status line updated with the v0.6.0 changelog
- docs/JSON_SCHEMA.md example refreshed
2026-05-23 00:22:18 -04:00
leviathan c00c3b463a dispatcher: per-detect timeout + exploit() fork-isolation
Two reliability improvements that make --auto survive any misbehaving
module: a 15s timeout on detect() so a hung probe can't stall the
scan, and fork-isolation around exploit/mitigate/cleanup so a
crashing callback doesn't take down --auto's fallback path.

Detect timeout:
- New SKELETONKEY_DETECT_TIMEOUT_SECS = 15.
- run_detect_isolated() forked child now calls alarm(15); if detect()
  hangs, SIGALRM kills the child. Parent observes WIFSIGNALED with
  signal SIGALRM and reports 'detect() timed out (signal 14)' in the
  verdict table.
- cmd_auto distinguishes timeout vs other crash in the scan-summary
  callout: separate n_timeout counter and dedicated [!] line.

Exploit fork-isolation:
- New run_callback_isolated() wraps exploit() / mitigate() / cleanup()
  in a forked child. Two crash-safety properties:
  * A SIGSEGV/SIGILL in the callback is contained; --auto continues
    to the next-safest candidate via its existing fallback list.
  * The dispatcher itself can't be killed by a misbehaving exploit.
- Result-code communication is via a one-byte pipe with FD_CLOEXEC on
  the write end:
  * Callback returns normally  -> child writes result byte, _exit;
                                  parent reads it; trusted result.
  * Callback execve()s a target -> FD_CLOEXEC closes the write end
                                  during the exec transition;
                                  parent's read() gets EOF; we treat
                                  exec-then-exit as EXPLOIT_OK
                                  regardless of the shell's exit
                                  code (we DID land code execution).
  * Callback crashes           -> WIFSIGNALED true; report the
                                  signal and propagate EXPLOIT_FAIL.
- cmd_auto: exploit() crash now logged distinctly ('[!] X exploit
  crashed (signal N) — dispatcher recovered'). Exec-path is
  surfaced too ('[*] X exploit transferred to spawned target — ...').
- cmd_one: same wrapping, same crash/exec reporting for the
  --exploit/--mitigate/--cleanup single-module paths.

Both platforms build clean. Verified containment behavior on Linux
in docker: entrybleed's prefetchnta SIGILL still reports cleanly as
'detect() crashed (signal 4) — continuing' and the scan finishes
through all 31 modules to the summary + pick step.
2026-05-22 23:26:09 -04:00
leviathan 4f30d00a1c core/host: shared host fingerprint refactor
Adds core/host.{h,c} — a single struct skeletonkey_host populated once
at startup and handed to every module callback via ctx->host. Replaces
the per-detect uname / /etc/os-release / sysctl / userns-fork-probe
calls scattered across the corpus with O(1) cached lookups, and gives
the dispatcher one consistent view of the host.

What's in the fingerprint:

- Identity: kernel_version (parsed from uname.release), arch (machine),
  nodename, distro_id / distro_version_id / distro_pretty (parsed once
  from /etc/os-release).
- Process state: euid, real_uid (defeats userns illusion via
  /proc/self/uid_map), egid, username, is_root, is_ssh_session.
- Platform family: is_linux, is_debian_family, is_rpm_family,
  is_arch_family, is_suse_family (file-existence checks once).
- Capability gates (Linux): unprivileged_userns_allowed (live
  fork+unshare probe), apparmor_restrict_userns,
  unprivileged_bpf_disabled, kpti_enabled, kernel_lockdown_active,
  selinux_enforcing, yama_ptrace_restricted.
- System services: has_systemd, has_dbus_system.

Wiring:

- core/module.h forward-declares struct skeletonkey_host and adds the
  pointer to skeletonkey_ctx. Modules opt-in by including
  ../../core/host.h.
- core/host.c is fully POD (no heap pointers) — uses a single file-
  static instance, returns a stable pointer on every call. Lazily
  populated on first skeletonkey_host_get().
- skeletonkey.c calls skeletonkey_host_get() at main() entry, stores
  in ctx.host before any register_*() runs.
- cmd_auto's bespoke distro-fingerprint code (was an inline
  read_os_release helper) is replaced with skeletonkey_host_print_banner(),
  which emits a two-line banner of identity + capability gates.

Migrations:

- dirtydecrypt: kernel_version_current() -> ctx->host->kernel.
- fragnesia: removed local fg_userns_allowed() fork-probe in favour of
  ctx->host->unprivileged_userns_allowed (no per-scan fork). Also
  pulls kernel from ctx->host. The PRECOND_FAIL message now notes
  whether AppArmor restriction is on.
- pack2theroot: access('/etc/debian_version') -> ctx->host->is_debian_family;
  also short-circuits when ctx->host->has_dbus_system is false (saves
  the GLib g_bus_get_sync attempt on systems without system D-Bus).
- overlayfs: replaced the inline is_ubuntu() /etc/os-release parser
  with ctx->host->distro_id comparison. Local helper preserved for
  symmetry / standalone builds.

Documentation: docs/ARCHITECTURE.md gains a 'Host fingerprint'
section describing the struct, the opt-in include pattern, and
example detect() usage. ROADMAP --auto accuracy log notes the
landing and flags remaining modules as an incremental follow-up.

Build verification:

- macOS (local): make clean && make -> Mach-O x86_64, 31 modules,
  banner prints with distro=?/? (no /etc/os-release).
- Linux (docker gcc:latest + libglib2.0-dev): make clean && make ->
  ELF 64-bit, 31 modules. Banner prints with kernel + distro=debian/13
  + 7 capability gates. dirtydecrypt correctly says 'predates the
  rxgk code added in 7.0'; fragnesia PRECOND_FAILs with
  '(host fingerprint)' annotation; pack2theroot PRECOND_FAILs on
  no-DBus; overlayfs reports 'not Ubuntu (distro=debian)'.
2026-05-22 23:18:00 -04:00
leviathan 3e6e0d869b skeletonkey: add --dry-run flag
Preview-only mode for --auto / --exploit / --mitigate / --cleanup.
Walks the full scan (with active probes, fork isolation, verdict
table — everything the real --auto does) and prints what would be
launched, without ever calling the exploit/mitigate/cleanup callback.

Wiring:
- struct skeletonkey_ctx gains a 'dry_run' field (core/module.h).
- Long option --dry-run, getopt case 10.
- cmd_auto: after picking the safest, if dry_run, print
    [*] auto: --dry-run: would launch `--exploit <NAME> --i-know`; not firing.
  plus the remaining ranked candidates, then return 0.
- cmd_one (used for --exploit/--mitigate/--cleanup) shorts on dry_run
  with [*] <module>: --dry-run: would run --<op>; not firing.

UX: --auto --dry-run does NOT require --i-know (nothing fires). The
refusal message for bare --auto now points to --dry-run for the
preview path:
  [-] --auto requires --i-know (or --dry-run for a preview that never fires).

ROADMAP --auto accuracy section updated with the dry-run + the
version-pinned detect work from the previous commit.

Smoke-tested locally on macOS: scanning runs, verdicts print, the
'would launch' line fires, exit 0.
2026-05-22 23:08:24 -04:00
leviathan a26f471ecf dirtydecrypt + fragnesia: pin CVE fix commits, version-based detect()
Both modules' detect() was precondition-only because we didn't know the
mainline fix commits at port time. Debian's security tracker now
provides them — pinning here turns detect() into a proper version-
based verdict (still with --active for empirical override).

dirtydecrypt (CVE-2026-31635):
- Fix commit a2567217ade970ecc458144b6be469bc015b23e5 in mainline 7.0
  ('rxrpc: fix oversized RESPONSE authenticator length check').
- Debian tracker confirms older stable branches (5.10 / 6.1 / 6.12) as
  <not-affected, vulnerable code not present>: the rxgk RESPONSE-
  handling code was added in 7.0.
- kernel_range table: { {7, 0, 0} }
- detect() pre-checks 'kernel < 7.0 -> SKELETONKEY_OK (predates)' then
  consults the table. With --active, the /tmp sentinel probe overrides
  empirically (catches pre-fix 7.0-rc kernels the version check
  reports as patched).

fragnesia (CVE-2026-46300):
- Fix in mainline 7.0.9 per Debian tracker ('linux unstable: 7.0.9-1
  fixed'). Older Debian-stable branches (bullseye 5.10 / bookworm 6.1
  / trixie 6.12) are still marked vulnerable as of 2026-05-22 - no
  backports yet.
- kernel_range table: { {7, 0, 9} }
- detect() keeps the userns + carrier preconditions, then consults
  the table: 7.0.9+ -> OK; older branches without an explicit backport
  entry -> VULNERABLE (version-only). --active confirms empirically.
- Table is intentionally minimal so distros that DO backport in the
  future flow into 'patched' once their branch lands an entry; until
  then, the conservative VULNERABLE verdict on unfixed branches is
  correct.

Other changes:
- module struct .kernel_range strings updated from 'fix commit not
  yet pinned' to the actual pinned-version prose.
- module_safety_rank bumped 86 -> 87 for both modules (version-pinned
  detect is now real; still below the verified copy_fail family at
  88 so --auto prefers verified modules when both apply).
- Both modules now #include core/kernel_range.h inside their
  #ifdef __linux__ block.
- MODULE.md verification-status sections rewritten: detect() is now
  version-pinned; only the exploit body remains unverified.
- CVES.md note + inventory rows updated: dropped the 'precondition-
  only' language for the pair; all three ported modules now have
  pinned fix references.
- README  tier description + module list aligned to the new state.

Both detect()s smoke-tested in docker gcc:latest on kernel 6.12.76-
linuxkit: dirtydecrypt correctly reports OK ('predates the rxgk code
added in 7.0'); fragnesia + pack2theroot correctly report
PRECOND_FAIL (no userns / no D-Bus in container). Local macOS + Linux
builds both clean.
2026-05-22 23:06:15 -04:00
leviathan 9a4cc91619 pack2theroot (CVE-2026-41651) + --auto accuracy work
Adds the third ported module — Pack2TheRoot, a userspace PackageKit
D-Bus TOCTOU LPE — and spends real effort hardening --auto so its
detect step gives an accurate, robust verdict before deploying.

pack2theroot (CVE-2026-41651):
- Ported from the public Vozec PoC
  (github.com/Vozec/CVE-2026-41651). Original disclosure by the
  Deutsche Telekom security team.
- Two back-to-back InstallFiles D-Bus calls (SIMULATE then NONE)
  overwrite the cached transaction flags between polkit auth and
  dispatch. GLib priority ordering makes the overwrite deterministic,
  not a timing race; postinst of the malicious .deb drops a SUID bash
  in /tmp.
- detect() reads PackageKit's VersionMajor/Minor/Micro directly over
  D-Bus and compares against the pinned fix release 1.3.5 (commit
  76cfb675). This is a high-confidence verdict, not precondition-only.
- Debian-family only (PoC builds its own .deb in pure C; ar/ustar/
  gzip-stored inline). Cleanup removes /tmp .debs + best-effort
  unlinks /tmp/.suid_bash + sudo -n dpkg -r the staging packages.
- Adds an optional GLib/GIO build dependency. The top-level Makefile
  autodetects via `pkg-config gio-2.0`; when absent the module
  compiles as a stub returning PRECOND_FAIL.
- Embedded auditd + sigma rules cover the file-side footprint
  (/tmp/.suid_bash, /tmp/.pk-*.deb, non-root dpkg/apt execve).

--auto accuracy improvements:
- Auto-enables --active before the scan. Per-module sentinel probes
  (page-cache /tmp files, fork-isolated namespace mounts) turn
  version-only checks into definitive verdicts, so silent distro
  backports don't fool the scan and --auto won't pick blind on
  TEST_ERROR.
- Per-module verdict printing — every module's result is shown
  (VULNERABLE / patched / precondition / indeterminate), not just
  VULNERABLE rows. Operator sees the full picture.
- Scan-end summary line: "N vulnerable, M patched/n.a., K
  precondition-fail, L indeterminate" with a separate callout when
  modules crashed.
- Distro fingerprint added to the auto banner (ID + VERSION_ID from
  /etc/os-release alongside kernel/arch).
- Fork-isolated detect() — each detector runs in a child process so
  a SIGILL/SIGSEGV in one module's probe is contained and the scan
  continues. Surfaced live while testing: entrybleed's prefetchnta
  KASLR sweep SIGILLs on emulated CPUs (linuxkit on darwin); without
  isolation the whole --auto died at module 7 of 31. With isolation
  the scan reports "detect() crashed (signal 4) — continuing" and
  finishes cleanly.

module_safety_rank additions:
- pack2theroot: 95 (userspace D-Bus TOCTOU; dpkg + /tmp SUID footprint
  — clean but heavier than pwnkit's gconv-modules-only path).
- dirtydecrypt / fragnesia: 86 (page-cache writes; one step below the
  verified copy_fail/dirty_frag family at 88 to prefer verified
  modules when both apply).

Docs:
- README badge / tagline / tier table /  block / example output /
  v0.5.0 status — all updated to "28 verified + 3 ported".
- CVES.md counts line, the ported-modules note (now calling out
  pack2theroot's high-confidence detect vs. precondition-only for
  the page-cache pair), inventory row, operations table row.
- ROADMAP Phase 7+: pack2theroot moved out of carry-overs into the
  "landed (ported, pending VM verification)" group; added a new
  "--auto accuracy work" subsection documenting the dispatcher
  hardening landed in this commit.
- docs/index.html: scanning-count example bumped to 31, status line
  updated to mention 3 ported modules.

Build verification: full `make clean && make` in `docker gcc:latest`
with libglib2.0-dev installed: links into a 31-module skeletonkey
ELF (413KB), `--list` shows all modules including pack2theroot,
`--detect-rules --format=auditd` emits the new pack2theroot section,
`--auto --i-know --no-shell` exercises the new banner + active
probes + verdict table + fork isolation + scan summary end-to-end.
Only build warning is the pre-existing
`-Wunterminated-string-initialization` in dirty_pipe (not introduced
here).
2026-05-22 22:42:07 -04:00
leviathan a8c8d5ef1f modules: add dirtydecrypt (CVE-2026-31635) + fragnesia (CVE-2026-46300)
Two new page-cache-write LPE modules, both ported from the public V12
security PoCs (github.com/v12-security/pocs):

- dirtydecrypt (CVE-2026-31635): rxgk missing-COW in-place decrypt.
  rxgk_decrypt_skb() decrypts spliced page-cache pages before the HMAC
  check, corrupting the page cache of a read-only file. Sibling of
  Copy Fail / Dirty Frag in the rxrpc subsystem.

- fragnesia (CVE-2026-46300): XFRM ESP-in-TCP skb_try_coalesce() loses
  the SHARED_FRAG marker, so the ESP-in-TCP receive path decrypts
  page-cache pages in place. A latent bug exposed by the Dirty Frag
  fix (f4c50a4034e6). Retires the old _stubs/fragnesia_TBD stub.

Both wrap the PoC exploit primitive in the skeletonkey_module
interface: detect/exploit/cleanup, an --active /tmp sentinel probe,
--no-shell support, and embedded auditd + sigma rules. The exploit
body runs in a forked child so the PoC's exit()/die() paths cannot
tear down the dispatcher. The fragnesia port drops the upstream PoC's
ANSI TUI (incompatible with a shared dispatcher); the exploit
mechanism is reproduced faithfully. Linux-only code is guarded with
#ifdef __linux__ so the modules still compile on non-Linux dev boxes.

VERIFICATION: ported, NOT yet validated end-to-end on a
vulnerable-kernel VM. The CVE fix commits are not pinned, so detect()
is precondition-only (PRECOND_FAIL / TEST_ERROR, never a blind
VULNERABLE) and --auto will not fire them unless --active confirms.
macOS stub-path compiles verified locally; the Linux exploit-path
build is covered by CI (build.yml, ubuntu) only. See each MODULE.md.

Wiring: core/registry.h, skeletonkey.c, Makefile, CVES.md, ROADMAP.md.
2026-05-22 18:22:30 -04:00
leviathan 0fbe1b058f v0.5.0: --auto mode + sysadmin one-liner
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
skeletonkey.c: new --auto subcommand. Scans every module's detect(),
    filters to VULNERABLE, ranks by safety (structural > page-cache >
    userspace > kernel-primitive > race), runs the safest exploit.
    Requires --i-know. If the safest fails, suggests next candidates.

  README.md: 'One-command root' Quickstart section showing
    curl … install.sh | sh && skeletonkey --auto --i-know
    — the sysadmin/red-team one-liner.

  Status: bumped 0.4.5 → 0.5.0; corpus 24 → 28 modules (4 new in
    parallel batch: sudo_samedit, sequoia, sudoedit_editor, vmwgfx).
2026-05-17 01:55:13 -04:00
leviathan 5a73565e0e scaffold: 4 new module dirs (sudo_samedit, sequoia, sudoedit_editor, vmwgfx)
Stubs returning PRECOND_FAIL. Parallel agents fill in real detect/exploit.
2026-05-17 01:47:28 -04:00
leviathan e668c3301f banner: drop ASCII art, plain text only
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
Replace the skeleton-key ASCII art with a single-line text banner.

Bump 0.4.4 → 0.4.5.
2026-05-16 23:05:40 -04:00
leviathan 347a9af832 banner: give the bit actual teeth
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
Previous staircase pattern was just trailing decoration — not real
key teeth. Redesigned the bit as a hanging rectangle with two
clearly-projecting notch-teeth on its right edge (the part that
engages a lock's wards). Switched to box-drawing chars for the bit
since they make sharper notches than 8/b/d glyphs; bow stays
ornate-ASCII style.

Bump 0.4.3 → 0.4.4.
2026-05-16 23:04:14 -04:00
leviathan 023289a03a banner: artwork is the focal point — plain SKELETONKEY text below
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
Previous banner had a SKELETONKEY block-letter art that competed
with the skeleton-key drawing for visual attention. Simplified:
the key art is now the focal point, and SKELETONKEY is rendered
as plain spaced text below the drawing.

Slight refinement to the key art: bow is a bit larger (888 instead
of 88) to feel more substantial. Bit/teeth pattern unchanged.

Bump 0.4.2 → 0.4.3.
2026-05-16 23:01:14 -04:00
leviathan e7ced5db7c banner: more detailed ornate skeleton key
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
The v0.4.1 box-drawing key was minimalist — round bow, line shaft,
small bit. Replaced with a more detailed ornate skeleton-key
silhouette in the classic ASCII-art-of-keys tradition:

  - Round bow with internal "hole" rendered via stylized 8/b/d/'
    pattern (suggests the decorative loop you'd grip)
  - Long shaft running right across the banner
  - Bit at the end with a staircase notch pattern (the iconic
    "key-tooth" descent showing the wards that engage the lock)

Same height as the previous banner. SKELETONKEY block letters
below unchanged.

Bump 0.4.1 → 0.4.2.
2026-05-16 22:57:01 -04:00
leviathan b5188b7818 banner: redesign skeleton key ASCII art
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
Replace the previous "circle + shaft + curl" silhouette (which read
more like a magnifying glass) with a proper skeleton-key anatomy:

  - BOW: round decorative loop with center hole (the part you hold)
  - SHAFT: long horizontal rod (= the body of the key)
  - BIT: notched tooth hanging down from the shaft end (the part
    that engages the lock — the iconic key-tooth profile)

Same change in skeletonkey.c BANNER and README.md.

Bump 0.4.0 → 0.4.1.
2026-05-16 22:52:13 -04:00
leviathan 9593d90385 rename: IAMROOT → SKELETONKEY across the entire project
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / release (push) Blocked by required conditions
Breaking change. Tool name, binary name, function/type names,
constant names, env vars, header guards, file paths, and GitHub
repo URL all rebrand IAMROOT → SKELETONKEY.

Changes:
  - All "IAMROOT" → "SKELETONKEY" (constants, env vars, enum
    values, docs, comments)
  - All "iamroot" → "skeletonkey" (functions, types, paths, CLI)
  - iamroot.c → skeletonkey.c
  - modules/*/iamroot_modules.{c,h} → modules/*/skeletonkey_modules.{c,h}
  - tools/iamroot-fleet-scan.sh → tools/skeletonkey-fleet-scan.sh
  - Binary "iamroot" → "skeletonkey"
  - GitHub URL KaraZajac/IAMROOT → KaraZajac/SKELETONKEY
  - .gitignore now expects build output named "skeletonkey"
  - /tmp/iamroot-* tmpfiles → /tmp/skeletonkey-*
  - Env vars IAMROOT_MODPROBE_PATH etc. → SKELETONKEY_*

New ASCII skeleton-key banner (horizontal key icon + ANSI Shadow
SKELETONKEY block letters) replaces the IAMROOT banner in
skeletonkey.c and README.md.

VERSION: 0.3.1 → 0.4.0 (breaking).

Build clean on Debian 6.12.86. `skeletonkey --version` → 0.4.0.
All 24 modules still register; no functional code changes — pure
rename + banner refresh.
2026-05-16 22:43:49 -04:00