Use-After-Free in Netfilter nf_tables durante l'elaborazione di richieste batch

Dettagli della vulnerabilità

Il codice affetto ha origine dal kernel Linux ufficiale di https://kernel.org/ e fa parte del componente Netfilter nf_tables (net/netfilter/nf_tables_api.c).

Netfilter nf_tables consente di aggiornare la propria configurazione come operazione atomica. Utilizzando questa funzionalità, i client in spazio utente inviano richieste batch contenenti un elenco di operazioni di base. Netfilter nf_tables elabora quindi tutte le operazioni all'interno del batch come un'unica transazione. Durante l'elaborazione del batch, Netfilter nf_tables controlla gli aggiornamenti dello stato della configurazione per garantire che ogni operazione di base successiva sia valida e questo tiene conto anche degli aggiornamenti di stato di tutte le operazioni precedenti all'interno del batch. Tuttavia, il controllo attualmente implementato è insufficiente.

Nel nostro scenario specifico partiamo da una configurazione di Netfilter nf_tables che ha una nft_rule con espressione lookup su un nft_set anonimo, e dove l'nft_set anonimo contiene alcuni elementi. Successivamente, inviamo una richiesta batch contenente le seguenti due operazioni di base:

1. Operazione NFT_MSG_DELRULE per eliminare la nft_rule.
   Si noti che questo elimina anche implicitamente l'espressione lookup e l'nft_set anonimo.
2. Operazione NFT_MSG_DELSETELEM per eliminare uno qualsiasi degli elementi dell'nft_set anonimo eliminato.

La versione attuale di Netfilter nf_tables accetta la richiesta batch sopra descritta. Chiama quindi nf_tables_commit_release() che aggiunge le risorse rilasciate a nf_tables_destroy_list. La nf_tables_destroy_list viene quindi elaborata da nf_tables_trans_destroy_work() che prima dealloca le risorse relative all'operazione NFT_MSG_DELRULE chiamando:

nft_commit_release()
    nf_tables_rule_destroy()
        nf_tables_expr_destroy()
            expr->ops->destroy() che punta a nft_lookup_destroy()
                nf_tables_destroy_set()
                    nft_set_destroy()
                        kvfree() che dealloca la memoria utilizzata da `nft_set`

prima di elaborare l'operazione NFT_MSG_DELSETELEM, dove il riferimento all'nft_set deallocato viene acceduto tramite nft_trans_elem_set() durante le seguenti chiamate:

nft_commit_release()
    nf_tables_set_elem_destroy()
        nft_set_elem_ext()

All'interno di nft_set_elem_ext() sopra, la posizione di memoria dell'nft_set deallocato viene acceduta per determinare la posizione di nft_set_ext:

static inline struct nft_set_ext *nft_set_elem_ext(const struct nft_set *set,
                                                   void *elem)
{
        return elem + set->ops->elemsize;
}

per le operazioni successive. Quindi, ogni volta che il valore di set->ops->elemsize viene corrotto, una posizione di memoria imprevista potrebbe essere interpretata come elenco di nft_expr da distruggere:

static void nf_tables_set_elem_destroy(const struct nft_ctx *ctx,
                                       const struct nft_set *set, void *elem)
{
        struct nft_set_ext *ext = nft_set_elem_ext(set, elem);

        if (nft_set_ext_exists(ext, NFT_SET_EXT_EXPRESSIONS))
                nft_set_elem_expr_destroy(ctx, nft_set_ext_expr(ext));

Tecniche di sfruttamento

Sfruttare la vulnerabilità sopra descritta richiede di vincere una corsa contro nf_tables_trans_destroy_work() che viene eseguita da un thread worker in background del kernel Linux. Ciò sembra complicare lo sfruttamento pratico anche prima di considerare le mitigazioni esistenti, come l'hardening dell'allocatore di slab del kernel, il Kernel Address Space Layout Randomization (KASLR) e specialmente il Control-Flow Integrity. Tuttavia, il PoC allegato dimostra che è ancora possibile ottenere uno sfruttamento ragionevolmente affidabile nella pratica.

Per sfruttare la vulnerabilità dobbiamo modificare il contenuto della memoria dell'nft_set dopo che è stato deallocato in nf_tables_rule_destroy(), ma prima che venga utilizzato in nf_tables_set_elem_destroy(). Sia nf_tables_rule_destroy() che nf_tables_set_elem_destroy() vengono chiamati all'interno di una singola invocazione di nf_tables_trans_destroy_work() che viene eseguita da un thread worker in background del kernel Linux. Inoltre, il chunk di memoria deallocato è solitamente disponibile per il riutilizzo solo dallo stesso core CPU.

Quando gareggiamo con nf_tables_trans_destroy_work(), miglioriamo le nostre possibilità aggiungendo un ritardo controllato per il thread worker in background tra le chiamate di nf_tables_rule_destroy() e nf_tables_set_elem_destroy(). Per fare ciò inseriamo un'operazione aggiuntiva per distruggere un altro nft_set contenente un numero elevato di elementi. Inoltre, manteniamo occupati tutti gli altri core CPU, in modo che il thread worker in background venga probabilmente schedulato su un core CPU specifico, così possiamo tentare di allocare una nuova struttura dallo stesso core CPU subito dopo che dealloca nft_set in nf_tables_rule_destroy(). Il nostro obiettivo è allocare un nuovo nft_set di tipo diverso per riutilizzare la posizione di memoria dell'nft_set deallocato in nf_tables_rule_destroy().

Il nuovo tipo di nft_set viene selezionato per utilizzare un valore diverso per set->ops->elemsize. Quindi, quando il thread worker in background finalmente chiama nf_tables_set_elem_destroy() per elaborare l'operazione NFT_MSG_DELSETELEM, interpreta il suo argomento elem in modo errato, in modo che l'nft_set_ext *ext corrotto si trovi pochi byte dopo la posizione corretta. Ciò significa che alcuni campi di dati controllati dall'utente dell'originale nft_set_ext vengono ora interpretati come intestazioni, risultando in una type confusion.

Un modo per abusare di questa type confusion è creare le intestazioni nft_set_ext corrotte con valori di offset tali che nf_tables_set_elem_destroy() interpreti il contenuto di blocchi di memoria adiacenti come l'elenco di nft_expr da distruggere tramite le seguenti chiamate:

nft_set_elem_expr_destroy()
    __nft_set_elem_expr_destroy()
        nf_tables_expr_destroy()
            expr->ops->destroy()

A questo punto dello sfruttamento, non abbiamo ancora dettagli del layout della memoria del kernel. Quindi non è possibile creare indirizzi di puntatore assoluti. Tuttavia, quando creiamo le intestazioni nft_set_ext corrotte possiamo ancora utilizzare offset fuori intervallo, in modo che expr->ops->destroy() venga chiamato su determinati nft_expr validi nei chunk di memoria adiacenti.

Per questo spruzziamo espressioni nft_log, con NFTA_LOG_PREFIX controllato. Il nft_log->prefix viene quindi deallocato da nft_log_destroy() una volta che expr->ops->destroy() viene chiamato:

static void nft_log_destroy(const struct nft_ctx *ctx,
                            const struct nft_expr *expr)
{
        struct nft_log *priv = nft_expr_priv(expr);
        struct nf_loginfo *li = &priv->loginfo;

        if (priv->prefix != nft_log_null_prefix)
                kfree(priv->prefix);

Si noti che possiamo ancora accedere e persino deallocare nuovamente questa memoria tramite l'altro riferimento dall'espressione nft_log spruzzata.

Inoltre, possiamo anche controllare la dimensione di nft_log->prefix, in modo che possa essere allocato da qualsiasi slab kmalloc-{8, ..., 192}. Infine, la memoria referenziata viene interpretata come una stringa di caratteri dal kernel, quindi non è necessario preoccuparsi di corruzioni quando sovrapponiamo oggetti diversi su di essa. Questo è essenzialmente game over.