⚠️ Disclaimer

Questo repository è destinato esclusivamente a ricerca di sicurezza autorizzata, analisi di vulnerabilità, CTF e test difensivi.

Non utilizzare questa ricerca contro sistemi di cui non si è proprietari o per i quali non si dispone di esplicita autorizzazione al test.

📌 Panoramica della vulnerabilità

🧬 Descrizione della vulnerabilità

La vulnerabilità è presente nel percorso di elaborazione IPv6 AH6.

Il codice interessato esegue la manipolazione del routing header tramite:

net/ipv6/ah6.c

Nello specifico, la logica vulnerabile coinvolge:

ipv6_rearrange_rthdr()

La funzione non è riuscita a validare adeguatamente la relazione tra:

hdrlen

e:

segments_left

Un attaccante in grado di fornire un pacchetto IPv6 appositamente craftato può quindi indurre il kernel a operare su memoria al di fuori dei limiti attesi del routing header.

Ciò può portare a:

Pacchetto IPv6 malformato
        │
        ▼
Elaborazione AH6 / XFRM
        │
        ▼
Stato del routing header non valido
        │
        ▼
Operazione di memoria fuori dai limiti
        │
        ▼
Corruzione della memoria del kernel
        │
        ▼
Potenziale escalation dei privilegi

🔬 Causa principale

Il problema fondamentale è la validazione insufficiente del valore segments_left dell'IPv6 Routing Header.

Concettualmente, la condizione vulnerabile può essere rappresentata come:

segments_left > indirizzi disponibili nel routing header

Il kernel deve garantire che il numero di segmenti richiesti dal routing header sia coerente con la lunghezza effettiva dell'header prima di manipolare i dati degli indirizzi associati.

Senza tale validazione, le successive operazioni di memoria possono operare oltre i limiti validi del buffer.

💥 Impatto sulla sicurezza

Lo sfruttamento riuscito può consentire a un attaccante con le necessarie capacità/ambiente locale di corrompere la memoria del kernel.

Le potenziali conseguenze includono:

• Corruzione della memoria del kernel
• Crash del kernel
• Denial of service
• Potenziale esecuzione arbitraria di codice nel kernel
• Escalation dei privilegi locale
• Potenziale transizione da un contesto non privilegiato a privilegi di kernel/root

L'effettiva sfruttabilità dipende dalla configurazione del kernel, dai namespace/capabilities disponibili e da altre condizioni ambientali.

🧪 Analisi tecnica

Componente vulnerabile

net/ipv6/ah6.c

Elaborazione rilevante:

AH6
 └── IPv6 Routing Header
      └── ipv6_rearrange_rthdr()

Lo scenario problematico coinvolge metadati del routing header incoerenti.

Ad esempio, concettualmente:

hdrlen        → descrive un numero limitato di indirizzi
segments_left → dichiara più indirizzi di quanti siano disponibili

Questa discrepanza deve essere rifiutata prima che il kernel esegua la riorganizzazione degli indirizzi.

🩹 Analisi della patch

La correzione upstream introduce la validazione del valore segments_left del Routing Header prima che il kernel esegua l'operazione vulnerabile.

Il commit upstream associato è:

7bad4bda74dc4713f398d3b7624ff05478e3a568

xfrm: ah6: validate routing header segments_left

La correzione di sicurezza può essere riassunta come:

Prima:
    Fiducia in segments_left
          ↓
    Riorganizzazione degli indirizzi
          ↓
    Potenziale accesso OOB

Dopo:
    Validazione di segments_left
          ↓
    Rifiuto dell'header malformato
          ↓
    Elaborazione AH6 sicura

🖥️ Versioni del kernel interessate

Le versioni interessate dipendono dalla cronologia upstream e dei backport dei vendor.

Gli utenti dovrebbero verificare l'advisory di sicurezza della propria distribuzione invece di basarsi solo sul numero di versione upstream.

Esempi di release stabili upstream corrette includono:

🔎 Rilevamento

Verificare il kernel in esecuzione:

uname -a

oppure:

uname -r

Verificare informazioni dettagliate sul kernel:

cat /proc/version

Per sistemi basati su Debian/Kali:

apt-cache policy linux-image-amd64

Per sistemi basati su RPM:

rpm -q kernel

I kernel delle distribuzioni spesso includono backport di correzioni di sicurezza senza modificare in modo evidente la versione upstream. Verificare sempre l'advisory/changelog del vendor.

🛡️ Mitigazione

La mitigazione principale consiste nell'aggiornare a un kernel che contenga la correzione di sicurezza.

Debian/Kali:

sudo apt update
sudo apt full-upgrade

Poi riavviare:

sudo reboot

Verificare:

uname -r

Per i sistemi in produzione, consultare l'advisory di sicurezza ufficiale della distribuzione Linux prima di applicare gli aggiornamenti del kernel.

🧰 Ambiente di ricerca

Ambiente isolato consigliato:

Host
 │
 ├── Kali Linux
 │
 └── VM Linux vulnerabile
       │
       ├── Kernel di debug
       ├── IPv6 abilitato
       ├── Supporto AH6/XFRM
       └── Simboli del kernel

Strumenti di debug utili:

gdb
gef
pwndbg
crash
dmesg
pahole
objdump
readelf

Debug del kernel:

sudo dmesg -w

Ispezionare i simboli del kernel:

cat /proc/kallsyms

📂 Struttura del repository

CVE-2026-80844-DirtyAH6/
│
├── README.md
│
├── exploit/
│   ├── poc.c
│   └── Makefile
│
├── analysis/
│   ├── vulnerability.md
│   ├── root-cause.md
│   └── patch-analysis.md
│
├── kernel/
│   ├── vulnerable.patch
│   └── fixed.patch
│
├── docs/
│   └── research-notes.md
│
├── screenshots/
│
└── LICENSE

🧪 Proof of Concept

Il materiale PoC dovrebbe essere eseguito esclusivamente all'interno di un ambiente di laboratorio isolato.

L'implementazione di ricerca si concentra sulla dimostrazione della condizione di IPv6 Routing Header malformato e sull'osservazione del comportamento risultante del kernel.

Flusso di ricerca previsto:

Craftare un header IPv6 malformato
          ↓
Trasmettere all'interno del laboratorio isolato
          ↓
Elaborazione AH6/XFRM
          ↓
Osservare il comportamento del kernel
          ↓
Catturare dmesg / informazioni sul crash
          ↓
Confrontare kernel vulnerabile vs corretto

Esempio di monitoraggio:

sudo dmesg -w

Un kernel corretto dovrebbe rifiutare l'input malformato senza raggiungere l'operazione di memoria vulnerabile.

📊 Vulnerabile vs corretto

🧠 Lezione di sicurezza chiave

Questa vulnerabilità dimostra perché i parser di rete del kernel non devono mai fidarsi dei campi di lunghezza o conteggio forniti da un attaccante.

Il parsing critico per la sicurezza dovrebbe seguire:

Input
 ↓
Validazione dei limiti
 ↓
Validazione delle relazioni
 ↓
Validazione dello stato
 ↓
Operazione di memoria

piuttosto che:

Input
 ↓
Operazione di memoria
 ↓
Validazione

Anche una piccola incoerenza tra due campi di metadati di un pacchetto può diventare una vulnerabilità di memory safety a livello di kernel.

📚 Riferimenti

• CVE: CVE-2026-80844
• Linux Kernel: IPv6 / XFRM / AH6
• Correzione upstream: 7bad4bda74dc4713f398d3b7624ff05478e3a568
• Titolo della correzione: xfrm: ah6: validate routing header segments_left