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

Demo

Dettagli della vulnerabilità

Il codice interessato proviene dal kernel Linux ufficiale da 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. Quando si utilizza 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 ciascuna operazione di base successiva sia valida e ciò 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 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.
   Nota 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 poi 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() that points to nft_lookup_destroy()
                nf_tables_destroy_set()
                    nft_set_destroy()
                        kvfree() that deallocates memory used by `nft_set`

prima di elaborare l'operazione NFT_MSG_DELSETELEM, dove il riferimento all'nft_set deallocato viene accesso 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 accessa 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 che seguono. Quindi, ogni volta che il valore di set->ops->elemsize viene corrotto, una certa posizione di memoria inaspettata potrebbe essere interpretata come un 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 race condition con nf_tables_trans_destroy_work() che viene eseguito da un thread worker in background del kernel Linux. Questo sembra complicare lo sfruttamento pratico ancor prima di considerare le mitigazioni esistenti, come l'hardening dell'allocatore slab del kernel, la randomizzazione del layout dello spazio degli indirizzi del kernel (KASLR) e specialmente l'integrità del flusso di controllo. Tuttavia, il PoC allegato dimostra che è comunque 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 della CPU.

Quando si compete con nf_tables_trans_destroy_work(), miglioriamo le nostre possibilità aggiungendo un ritardo controllato per il thread worker in background tra le chiamate a nf_tables_rule_destroy() e nf_tables_set_elem_destroy(). Per questo inseriamo un'operazione aggiuntiva per distruggere un altro nft_set contenente un gran numero di elementi. Inoltre, manteniamo occupati tutti gli altri core della CPU, in modo che il thread worker in background venga probabilmente schedulato su un core specifico della CPU, così possiamo tentare di allocare una nuova struttura dallo stesso core della CPU subito dopo che ha deallocato 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 chiama finalmente nf_tables_set_elem_destroy() per elaborare l'operazione NFT_MSG_DELSETELEM, interpreta il suo argomento elem in modo errato, cosicché il nft_set_ext *ext corrotto si trova alcuni byte dopo la posizione corretta. Ciò significa che determinati campi dati controllati dall'utente dell'nft_set_ext originale vengono ora interpretati come intestazioni, risultando in una type confusion.

Un modo per abusare di questa type confusion è creare intestazioni nft_set_ext corrotte con valori di offset tali che nf_tables_set_elem_destroy() interpreti il contenuto di eventuali 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 puntatori assoluti. Tuttavia, quando creiamo le intestazioni nft_set_ext corrotte possiamo comunque utilizzare offset fuori range, in modo che expr->ops->destroy() venga chiamato su certi nft_expr validi nei chunk di memoria adiacenti.

Per questo spruzziamo espressioni nft_log, con NFTA_LOG_PREFIX controllato. Quel 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);

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