Third attempt at arm64-static. Previous two:
1. Alpine container on ubuntu-24.04-arm:
'JavaScript Actions in Alpine containers only supported on x64
Linux runners' — actions/checkout JS bundle can't run.
2. musl-tools on ubuntu-24.04-arm:
musl-gcc + Ubuntu's /usr/include collide. -isystem /usr/include
pulls glibc stdio.h whose __gnuc_va_list + __time64_t types
conflict with musl's stdio.h. -isystem /usr/include/linux alone
leaves us missing asm/ headers.
dockcross/linux-arm64-musl avoids both:
- Image base is Debian (glibc) → actions/checkout works.
- Ships aarch64-linux-musl-gcc with a CONSISTENT musl + linux-
uapi sysroot. No header collision.
The dockcross pattern is: pull the image, ask it to spit out its
wrapper script ('docker run --rm dockcross/linux-arm64-musl' prints
a bash wrapper to stdout), then './dockcross bash -c ...' runs the
command inside the toolchain container with the cwd volume-mounted.
Produces a statically-linked aarch64 ELF binary, same packaging
flow as the x86_64-static job.
Previous attempt failed with:
modules/copy_fail_family/src/apparmor_bypass.c:23:10:
fatal error: linux/capability.h: No such file or directory
musl-gcc points at musl's libc headers, which (correctly) don't
include Linux kernel uapi (linux/netfilter/*.h, linux/capability.h,
etc.). On Ubuntu these come from the linux-libc-dev package living
at /usr/include + /usr/include/aarch64-linux-gnu.
Fix: -isystem both paths so musl-gcc can find Linux uapi without
those paths shadowing musl's own libc decls (which they would if
we used a plain -I). The Alpine x86_64 build doesn't hit this
because Alpine's linux-headers package installs into musl's own
include path.
The v0.7.1 arm64-static build failed with:
'JavaScript Actions in Alpine containers are only supported on
x64 Linux runners. Detected Linux Arm64'
actions/checkout (and most other GitHub Actions) ship as Node.js
bundles. On x86_64, GitHub's runner injects a glibc-compatible Node
into Alpine containers; on arm64, that injection isn't available.
The container fails to even check out the repo.
Fix: run the arm64 static build natively on ubuntu-24.04-arm (a
glibc-based runner that actions/checkout works on out of the box),
and use Ubuntu's musl-tools package to get musl-gcc + musl-dev for
the static link. The produced binary is still statically-linked
against musl — just built outside an Alpine container.
Refactor: the previous build-static matrix becomes two distinct
jobs (build-static-x86_64 still Alpine-on-x64; build-static-arm64
now musl-tools-on-arm64). The release job's needs[] list and the
artifact list are unchanged at the consumer level — the same four
binaries (x86_64 dyn + static, arm64 dyn + static) plus install.sh
still get published.
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.
Bumps SKELETONKEY_VERSION to 0.7.0 and adds docs/RELEASE_NOTES.md with
the full v0.7.0 changelog. release.yml updated to use the hand-written
notes file as the GitHub Release body (falls back to the auto-generated
stub when docs/RELEASE_NOTES.md isn't present, so older tags still
publish cleanly).
Headline: empirical VM verification across 22 of 26 CVEs, plus the
--explain operator briefing mode, OPSEC notes per module, CISA KEV +
NVD CWE + MITRE ATT&CK metadata pipeline, 119 detection rules across
all 4 SIEM formats, kernel.ubuntu.com mainline kernel fetch path, and
the new marketing-grade landing page. Full breakdown in
docs/RELEASE_NOTES.md.
Tag v0.7.0 next; release workflow auto-builds + publishes the 3
binaries (x86_64 dynamic, x86_64 static-musl via Alpine, arm64
dynamic) with checksums.
Adds a third matrix job that builds a static-musl binary on Alpine
so future tags ship 4 assets per arch: dynamic + static.
The dynamic x86_64 build (gcc on ubuntu-latest) hits a glibc-version
ceiling — built against glibc 2.39, refuses to run on Debian 12
(2.36), RHEL 8/9, etc. install.sh now fetches the static asset by
default for x86_64; the dynamic remains available via
SKELETONKEY_DYNAMIC=1.
Static build details:
- Alpine container (native musl + linux-headers from apk).
- -DMSG_COPY=040000 covers the only musl-vs-glibc gap
(netfilter_xtcompat uses MSG_COPY, which is a Linux-kernel
constant that glibc exposes but musl omits — kernel header:
include/uapi/linux/msg.h).
- LDFLAGS=-static produces a static-PIE ELF (~1.2 MB).
- Cross-distro verified locally: Alpine-built binary runs on
Debian/Ubuntu/Fedora/RHEL.
Locally-built static binary was uploaded to v0.6.2 by hand to
unblock the one-liner installer immediately.
The v0.1.0 tag's arm64 job failed with
fatal error: bits/wordsize.h: No such file or directory
because gcc-aarch64-linux-gnu alone doesn't pull in the cross libc
headers on Ubuntu 24.04 runners. Add libc6-dev-arm64-cross +
linux-libc-dev-arm64-cross so the cross-toolchain has its sysroot.
For 'people should say just use iamroot' framing, the install gate is
the single biggest discoverability bottleneck. This commit makes it:
curl -sSL https://github.com/KaraZajac/IAMROOT/releases/latest/download/install.sh | sh
.github/workflows/release.yml:
- Triggers on semver tag push (v*.*.*) + manual dispatch.
- Matrix build for x86_64 (gcc) and arm64 (aarch64-linux-gnu-gcc cross).
- Per-arch sha256sum alongside the binary.
- Auto-generates release notes pointing at CVES.md / ROADMAP.md and
including the install one-liner with the version-specific URL.
- Publishes via softprops/action-gh-release@v2.
install.sh (also uploaded as a release artifact, so the curl|sh
above is stable):
- Detects arch (x86_64 / aarch64 → arm64).
- Pulls iamroot-<arch> + iamroot-<arch>.sha256 from the requested
version (default: latest).
- Verifies sha256 via sha256sum or shasum -a 256.
- Installs to /usr/local/bin/iamroot (or $IAMROOT_PREFIX). Uses sudo
iff /usr/local/bin isn't already writable.
- Prints quickstart hints + ethics pointer at the end.
- Env knobs: IAMROOT_VERSION, IAMROOT_PREFIX, IAMROOT_REPO.
README.md gains a 'Quickstart' section at the top with the four
canonical commands: install, --scan, --audit, --detect-rules,
fleet-scan. Lands the 'curl|bash and go' UX as the first thing
visitors see.
leviathan