Use-After-Free en Netfilter nf_tables al procesar solicitudes por lotes

Detalles de la vulnerabilidad

El código afectado se origina del kernel oficial de Linux de https://kernel.org/ y es parte del componente Netfilter nf_tables (net/netfilter/nf_tables_api.c).

Netfilter nf_tables permite actualizar su configuración como una operación atómica. Al usar esta característica, los clientes en modo usuario envían solicitudes por lotes que contienen una lista de operaciones básicas. Netfilter nf_tables entonces procesa todas las operaciones dentro del lote como una sola transacción. Al procesar el lote, Netfilter nf_tables verifica las actualizaciones de estado de la configuración para asegurar que cada operación básica sucesiva sea válida y esto también tiene en cuenta las actualizaciones de estado de todas las operaciones anteriores dentro del lote. Sin embargo, la verificación actualmente implementada es insuficiente.

En nuestro escenario específico comenzamos con una configuración de Netfilter nf_tables que tiene una nft_rule con expresión lookup en un nft_set anónimo, y donde el nft_set anónimo contiene algunos elementos. A continuación, enviamos una solicitud por lotes que contiene las siguientes dos operaciones básicas:

1. Operación NFT_MSG_DELRULE para eliminar la nft_rule.
   Tenga en cuenta que esto también elimina implícitamente la expresión lookup y el nft_set anónimo.
2. Operación NFT_MSG_DELSETELEM para eliminar cualquiera de los elementos del nft_set anónimo eliminado.

La versión actual de Netfilter nf_tables acepta la solicitud por lotes anterior. Luego llama a nf_tables_commit_release() que añade los recursos liberados a nf_tables_destroy_list. El nf_tables_destroy_list es luego procesado por nf_tables_trans_destroy_work() que primero desasigna los recursos relacionados con la operación NFT_MSG_DELRULE llamando a:

nft_commit_release()
    nf_tables_rule_destroy()
        nf_tables_expr_destroy()
            expr->ops->destroy() que apunta a nft_lookup_destroy()
                nf_tables_destroy_set()
                    nft_set_destroy()
                        kvfree() que desasigna la memoria usada por `nft_set`

antes de procesar la operación NFT_MSG_DELSETELEM, donde la referencia al nft_set desasignado se accede mediante nft_trans_elem_set() durante las siguientes llamadas:

nft_commit_release()
    nf_tables_set_elem_destroy()
        nft_set_elem_ext()

Dentro de nft_set_elem_ext() anterior, se accede a la ubicación de memoria del nft_set desasignado para determinar la ubicación de 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;
}

para las operaciones que siguen. Así que siempre que el valor de set->ops->elemsize se corrompa, cierta ubicación de memoria inesperada podría interpretarse como lista de nft_expr a destruir:

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));

Técnicas de explotación

Explotar la vulnerabilidad anterior requiere ganar una carrera contra nf_tables_trans_destroy_work() que se ejecuta desde un hilo trabajador en segundo plano del kernel de Linux. Esto parece complicar la explotación práctica incluso antes de considerar las mitigaciones existentes, como el endurecimiento del asignador de losas del kernel, la Aleatorización del Diseño del Espacio de Direcciones del Kernel (KASLR) y especialmente la Integridad del Flujo de Control. Sin embargo, el PoC adjunto demuestra que aún es posible lograr una explotación razonablemente confiable en la práctica.

Para explotar la vulnerabilidad necesitamos modificar el contenido de la memoria de nft_set después de que se desasigna bajo nf_tables_rule_destroy(), pero antes de que se use bajo nf_tables_set_elem_destroy(). Ambas nf_tables_rule_destroy() y nf_tables_set_elem_destroy() son llamadas dentro de una sola invocación de nf_tables_trans_destroy_work() que se ejecuta desde un hilo trabajador en segundo plano del kernel de Linux. Además, el fragmento de memoria desasignado generalmente está disponible para su reutilización solo desde el mismo núcleo de CPU.

Al competir con nf_tables_trans_destroy_work(), mejoramos nuestras posibilidades al agregar un retardo controlado para el hilo trabajador en segundo plano entre sus llamadas a nf_tables_rule_destroy() y nf_tables_set_elem_destroy(). Para eso insertamos una operación adicional para destruir otro nft_set que contiene un gran número de elementos. Adicionalmente, mantenemos todos los demás núcleos de CPU ocupados, de modo que es probable que el hilo trabajador en segundo plano se programe en un núcleo de CPU específico, para poder intentar asignar una nueva estructura desde el mismo núcleo de CPU justo después de que desasigne nft_set bajo nf_tables_rule_destroy(). Nuestro objetivo es asignar un nuevo nft_set de diferente tipo para reutilizar la ubicación de memoria del nft_set desasignado bajo nf_tables_rule_destroy().

El nuevo tipo de nft_set se selecciona para usar un valor diferente para set->ops->elemsize. Así que cuando el hilo trabajador en segundo plano finalmente llama a nf_tables_set_elem_destroy() para procesar la operación NFT_MSG_DELSETELEM, interpreta su argumento elem incorrectamente, de modo que el nft_set_ext *ext corrupto está unos bytes después de la ubicación correcta. Esto significa que ciertos campos de datos controlados por el usuario del nft_set_ext original ahora se interpretan como encabezados, resultando en una confusión de tipos.

Una forma de abusar de esta confusión de tipos es manipulando los encabezados del nft_set_ext corrupto con valores de desplazamiento tales que nf_tables_set_elem_destroy() interprete el contenido de cualquier bloque de memoria adyacente como la lista de nft_expr a destruir a través de las siguientes llamadas:

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

En este punto de la explotación, aún no tenemos detalles del diseño de la memoria del kernel. Por lo tanto, no es posible manipular direcciones de puntero absolutas. Sin embargo, al manipular los encabezados del nft_set_ext corrupto aún podemos usar desplazamientos fuera de rango, de modo que se llame a expr->ops->destroy() en ciertos nft_expr válidos en los fragmentos de memoria adyacentes.

Para ello, esparcimos expresiones nft_log, con un NFTA_LOG_PREFIX controlado. Ese nft_log->prefix es luego desasignado por nft_log_destroy() una vez que se llama a expr->ops->destroy():

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);

Tenga en cuenta que aún podemos acceder e incluso desasignar nuevamente esta memoria a través de la otra referencia desde la expresión nft_log esparcida.

Adicionalmente, también podemos controlar el tamaño de nft_log->prefix, de modo que pueda asignarse desde cualquiera de las losas kmalloc-{8, ..., 192}. Finalmente, la memoria referida es interpretada como una cadena de caracteres por el kernel, por lo que no hay que preocuparse por corrupciones cuando superponemos diferentes objetos sobre ella. Esto es esencialmente el final del juego.