Kit di contenimento per LPE della Page-Cache

Rileva, contieni e verifica le difese contro due escalation dei privilegi locali su Linux dovute alla corruzione della page-cache — DirtyClone (CVE-2026-43503) e pedit COW (CVE-2026-46331) — su host e container.

Questo è un kit di sicurezza educativo e difensivo. Spiega come funzionano entrambe le vulnerabilità a livello di syscall e include strumenti di hardening, rilevamento, verifica e seccomp — oltre a un harness di validazione che dimostra che gli strumenti funzionano su kernel reali. Non contiene exploit, shellcode o offset target, di proposito.

Indice

• Perché esiste
• La vulnerabilità in 30 secondi
• Avvio rapido
• Cosa contiene
• Requisiti
• Ambito ed etica
• Per saperne di più
• Contribuire
• Licenza

Perché esiste

Entrambe le CVE consentono a un utente locale non privilegiato di diventare root corrompendo la page cache (la copia in RAM) di un binario con setuid root come /usr/bin/su — senza toccare mai il file su disco. Questo le rende furtive: il monitoraggio dell'integrità dei file rimane verde, la forense del disco non trova nulla e la corruzione si azzera al riavvio.

La vera soluzione è applicare la patch al kernel. Ma durante la finestra di distribuzione — e successivamente come difesa in profondità — devi chiudere i percorsi d'attacco, osservare la catena d'attacco e verificare la tua postura. È ciò che offre questo kit, con ogni controllo ricondotto a un passo documentato della catena dell'exploit, così puoi vedere perché funziona.

La vulnerabilità in 30 secondi

Entrambi i bug appartengono alla stessa classe di difetti: il kernel scrive in un buffer che ritiene privato mentre quel buffer è ancora supportato da memoria page-cache condivisa e basata su file. Due porte strutturali governano ogni variante di entrambe le catene:

Corretto a monte nelle release puntuali stabili (DirtyClone ≥ 6.12.91 / 7.0.10; pedit COW 6.12.94 / 7.0.13) più i backport dei vendor; il mainline 7.1 è definitivo. Verifica il tuo kernel sul tracker della tua distribuzione — vedi docs/analysis.md §8.

Avvio rapido

Solo host Linux. Questi script leggono e scrivono lo stato reale del kernel. Esegui l'hardening su un host che controlli; esegui l'harness di validazione distruttivo su una VM monouso. Vedi Requisiti.

# 1. Preview the host containment changes (writes nothing)
sudo ./kit/harden-pagecache-lpe.sh --dry-run

# 2. Apply userns restrictions + vulnerable-module blocks
sudo ./kit/harden-pagecache-lpe.sh

# 3. Verify posture — run the functional probe as an UNPRIVILEGED user
sudo -u nobody ./kit/verify-pagecache-lpe.sh        # exit: 0=PASS 1=WARN 2=FAIL

# 4. (Optional) Watch the attack chain live with eBPF
sudo bpftrace ./kit/detect-pagecache-lpe.bt

Per i container, applica l'overlay seccomp (kit/seccomp-pagecache-lpe.json):

docker run --security-opt seccomp=kit/seccomp-pagecache-lpe.json <image>

Nuovo qui? Leggi START-HERE.md — un percorso guidato, in stile lezione, dalla causa principale fino a una run di validazione completa.

Cosa contiene

.
├── START-HERE.md          Guided walkthrough — the recommended entry point
├── docs/                  The "why": analysis and operator guidance
│   ├── analysis.md                Root-cause analysis, attack chains, detection engineering
│   ├── HARDENING-GUIDE.md         Operator containment guide (host → systemd → Docker → Kubernetes)
│   └── plain-language-summary.md  Gentler, plain-English overview of both bugs
├── kit/                   The "what you run": four self-contained artifacts
│   ├── harden-pagecache-lpe.sh    Apply host containment (sysctl + module blocks)
│   ├── verify-pagecache-lpe.sh    Read-only posture check (PASS/WARN/FAIL)
│   ├── detect-pagecache-lpe.bt    bpftrace/eBPF telemetry for the staging chain
│   └── seccomp-pagecache-lpe.json Container seccomp overlay denying the chain's syscalls
└── testkit/               The "proof": validation harness + SHOWCASE.md writeup

Requisiti

• Hardening e verifica (harden, verify): un host Linux con bash, sysctl, modprobe e unshare. È richiesto root per l'hardening; esegui la sonda di verifica come utente non root.
• Rilevamento (detect-pagecache-lpe.bt): richiede root, bpftrace ≥ 0.16 e kernel BTF (/sys/kernel/btf/vmlinux). Alcuni kprobe potrebbero essere inline su un dato kernel — l'intestazione dello script spiega come adattarsi.
• Overlay seccomp: qualsiasi runtime OCI (Docker, Podman, containerd).
• Harness di validazione (testkit/): una VM Linux monouso — scrive configurazione reale e rimuove i moduli del kernel. Il launcher EC2 richiede AWS CLI v2 e jq; non viene usato SSH (il trasporto è AWS SSM). Gli utenti macOS possono eseguire lo smoke test Docker locale, ma la validazione completa richiede Linux.

Ambito ed etica

TLP:CLEAR — distribuzione pubblica, senza restrizioni. Questo repository è solo rilevamento e prevenzione. Include deliberatamente:

• Analisi della causa principale a livello di syscall / sottosistema del kernel
• Strumenti di hardening, rilevamento, verifica e seccomp
• Un harness di validazione che esercita le difese

…ed esclude deliberatamente:

• Codice exploit eseguibile, payload proof-of-concept o shellcode
• Derivazione di scrittura controllata o offset target
• Qualsiasi elemento che faccia avanzare la weaponizzazione

I limiti onesti di questo approccio — cosa la validazione dimostra e cosa non dimostra — sono documentati in testkit/SHOWCASE.md §8. Usalo solo su sistemi di tua proprietà o su cui sei autorizzato a testare. L'hardening è contenimento, non una cura: applica la patch al kernel.

Per saperne di più

• START-HERE.md — il percorso guidato (inizia qui)
• docs/analysis.md — l'analisi tecnica completa
• docs/plain-language-summary.md — una panoramica più accessibile in inglese semplice

Contribuire

Issue e pull request sono benvenute — vedi CONTRIBUTING.md. Poiché i controlli sono rispecchiati su più file (l'elenco dei moduli, le manopole userns, la bitmap di rilevamento), leggi gli invarianti di sincronizzazione in quella guida prima di modificare la superficie d'attacco.

Licenza

Rilasciato sotto la Apache License 2.0.