Vulnerabilidad en kernel de Linux (CVE-2023-53024)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Fix pointer-leak due to lowest speculative store bypass mitigation Para mitigar Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to lowest speculative store bypass mitigation") inserta instrucciones lfence después de 1) inicializar una ranura de pila y 2) derramar un puntero a la pila. Sin embargo, esto no cubre los casos en los que una ranura de pila se inicializa primero con un puntero (sujeto a depuración) pero luego se sobrescribe con un escalar (no sujeto a depuración porque la ranura ya estaba inicializada). En este caso, la segunda escritura puede estar sujeta a la derivación de almacén especulativo (SSB), creando una confusión de tipo de puntero especulativo como escalar. Esto permite que el programa filtre posteriormente el valor del puntero numérico utilizando, por ejemplo, un canal lateral de caché basado en bifurcación. Para solucionar esto, también depura los escalares si escriben en una ranura de pila que anteriormente contenía un puntero. Suponiendo que los derrames de puntero solo son generados por LLVM bajo presión de registro, el impacto en el rendimiento de la mayoría de los programas BPF del mundo real debería ser mínimo. El siguiente código de bytes BPF sin privilegios describe un exploit mínimo y su mitigación: [...] // r6 = 0 o 1 (escalar, entrada de usuario desconocida) // r7 = ptr accesible para canal lateral // r10 = puntero de trama (fp), a filtrar // r9 = r10 # alias de fp para fomentar ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, a filtrar // Se añadió lfence debido al derrame de puntero a la pila. // // Omitido: bpf_ringbuf_output() ficticio para entrenar el predictor de alias // para la ausencia de dependencia entre r9 y r10. // *(u64 *)(r10 - 8) = r6 // fp[-8] = escalar, sobrescribe ptr // 2039f26f3aca: no se agregó lfence porque la ranura de pila no era STACK_INVALID, // el almacenamiento puede estar sujeto a SSB // // corrección: también se agrega una lfence cuando la ranura contenía un ptr // r8 = *(u64 *)(r9 - 8) // r8 = arquitectónicamente un escalar, especulativamente un ptr // // fuga de ptr usando el canal lateral de caché basado en ramas: r8 &= 1 // elige el bit a fugar si r8 == 0 goto SLOW // sin predicción errónea // código arquitectónicamente muerto si la entrada r6 es 0, // solo se ejecuta especulativamente si el bit ptr es 1 r8 = *(u64 *)(r7 + 0) # codificar bit en caché (0: lento, 1: rápido) SLOW: [...] Después de ejecutar esto, el programa Puede cronometrar el acceso a *(r7 + 0) para determinar si el bit de puntero seleccionado era 0 o 1. Repita esto 64 veces para recuperar la dirección completa en amd64. En resumen, la depuración solo se puede omitir si un escalar se sobrescribe con otro. La confusión escalar debido a la omisión del almacenamiento especulativo no puede conducir a accesos inválidos porque los límites del puntero deducidos durante la verificación se aplican mediante lógica sin ramificaciones. Consulte 979d63d50c0c ("bpf: evitar especulación fuera de los límites en aritmética de punteros") para obtener más detalles. No haga que la mitigación dependa de !env->allow_{uninit_stack,ptr_leaks} porque es probable que se produzcan fugas especulativas inesperadas si se habilitan. Por ejemplo, filtrar la dirección a un archivo de registro protegido puede ser aceptable, mientras que deshabilitar la mitigación podría filtrar involuntariamente la dirección al estado en caché de un mapa al que pueden acceder procesos sin privilegios.