Tres formas de entrar, una única salida a través de `ObfDereferenceObject`.

Eso no significa que el código sea incorrecto. Significa que el **invariante está distribuido** — ninguna función posee en exclusiva *«este objeto sigue vivo ahora mismo»*, por lo que la corrección depende de que cada llamador se ponga de acuerdo sobre qué referencia tiene y durante cuánto tiempo es válida. Los invariantes distribuidos son donde viven las condiciones de carrera, porque una carrera nunca es un bug lógico que puedas ver en una sola función. Es un bug en una suposición compartida entre dos.

Así que la pregunta que empecé a hacerle a cada función que tocaba un `PWND` no era *«¿es correcto este código?»*, sino:

> **Si este cuerpo de función exacto se ejecuta en dos hilos con unas pocas instrucciones de diferencia, ¿cuál de ellos es el equivocado?**

## 3. Causa raíz

El defecto es una **brecha de tiempo de comprobación / tiempo de uso entre la liberación de la referencia y la destrucción del objeto** en la ruta de destrucción de la ventana, sin sincronización adecuada frente a un consumidor concurrente que valida el handle.

En esencia:```c
/* Thread A — teardown */
NtUserDestroyWindow(HWND hwnd)
{
    PWND pWnd = ValidateHwnd(hwnd);
    if (pWnd) {
        ObfDereferenceObject(pWnd);   /* reference released */

        /* <-- race window: object may become reclaimable here */

        FreeWindowObject(pWnd);       /* teardown proceeds on a pointer
                                         no longer guaranteed live      */
    }
}

if (pWnd->fnid == FNID_BUTTON)    /* use-after-free */
    ...

Dos cosas tienen que ser ciertas para que esto importe, y ambas lo eran:

**(a) La ventana es real.** `ValidateHwnd` es la puerta que se supone que hace seguro el acceso basado en identificadores. Si la validación puede tener éxito contra un objeto cuyo desmontaje ya ha comenzado, la puerta no es una puerta — es una sugerencia.

**(b) La memoria liberada es influenciable por el atacante.** Los campos leídos inmediatamente después de la validación incluyen `fnid`, que impulsa el despacho de mensajes. Una decisión de despacho tomada desde memoria reclamada es la diferencia entre *"caída no fiable"* y *"violación del límite de seguridad"*. Esa distinción es la razón completa por la que esto es CWE-362 con impacto de EoP y no un error de estabilidad.

> La **corrupción** observada es un use-after-free; la **causa** es CWE-362, ejecución concurrente que usa un recurso compartido con sincronización inadecuada. Son dos afirmaciones distintas y a MSRC le importa la segunda. **Reporta la causa, no solo el síntoma.**

### Por qué las carreras de win32k son estructuralmente más difíciles de lo que parecen

Si has corrido contra errores en otros subsistemas, win32k te frustrará, porque la arquitectura lucha contra ti de tres maneras específicas.

**Las ventanas tienen afinidad de hilo.** Una ventana pertenece al hilo que la creó. Gran parte del subsistema está construida sobre la suposición de que el hilo propietario es el que toca el objeto, lo que significa que el enfoque ingenuo de "hacer girar dos hilos llamando a la misma API" frecuentemente no superpone nada — no estás corriendo, estás haciendo cola. Conseguir que dos rutas colisionen genuinamente sobre el mismo objeto requiere entender qué operaciones se ejecutan realmente en el hilo del llamador frente a cuáles se serializan al propietario.

**El despacho de mensajes te serializa parcialmente.** Los envíos y las publicaciones se comportan de manera distinta, y el despacho entre hilos se comporta diferente al de un mismo hilo. Parte de lo que parece una oportunidad de concurrencia se convierte silenciosamente en una operación ordenada antes de llegar al código que te importa. Si no sabes en qué categoría cae tu desencadenante, concluirás que una carrera real es inalcanzable — un falso negativo que se ve idéntico a "no hay ningún error aquí".

**La sección crítica se esconde en el llamador.** Gran parte del subsistema se ejecuta bajo un bloqueo grueso adquirido muy por encima de la función que estás mirando. Esta es la mayor fuente de tiempo desperdiciado en la auditoría de win32k: una función sin sincronización visible que, sin embargo, es perfectamente segura porque cada ruta hacia ella ya está serializada. **La cobertura de bloqueos es una propiedad interprocedural.** Debes subir por el grafo de llamadas, no solo leer la función.

Ese tercer punto es por lo que *"no hay bloqueo en esta función"* vale casi nada como señal, y por qué la mayor parte del trabajo en esta búsqueda se gastó en la alcanzabilidad, no en el defecto en sí.

## 4. Por qué la calificación de impacto es la que es

MSRC evaluó esto como **Importante, Elevación de Privilegios, CVSS 8.8, vector de ataque local, autenticado.** Dos propiedades impulsan eso:

**Alcanzabilidad desde integridad baja.** La superficie de llamadas de mensajes de Win32k es alcanzable desde contextos muy por debajo de SYSTEM. Eso es lo que lo hace relevante para cadenas de escape de sandbox — un proceso de renderizado que ya ha logrado ejecución de código dentro de su sandbox aún puede alcanzar esta superficie. La gravedad de un error de kernel es principalmente una función de *quién puede tocarlo*, no de lo ingeniosa que sea la corrupción.

**Corrupción que influye en el despacho.** Corromper un campo sobre el que corre un `switch` es cualitativamente peor que corromper un campo que solo se registra. Lo primero convierte un error de memoria en una cuestión de flujo de control.

Quiero ser preciso sobre algo aquí, porque he visto publicaciones de primer CVE exagerar esto: **Demostré la carrera y el use-after-free. No entregué un exploit weaponizado a nivel de SYSTEM.** El encuadre de escape de sandbox describe la *clase de cadena* a la que pertenece este tipo de error y por qué la superficie es valiosa — es un argumento sobre alcanzabilidad, no una afirmación de que construí una. Exagerar el impacto es la forma más rápida de quemar la credibilidad con un proveedor, y la evaluación de MSRC es el número que importa, no el mío.

## 5. La falsificación llegó primero — la mayoría de los candidatos murieron

La parte de la que nadie escribe: este no fue el primer candidato. Fue el que sobrevivió.

Mi regla de trabajo es que **un candidato es culpable hasta que se demuestre culpable.** Cada patrón prometedor recibe una razón específica y escrita de por qué *no debería* ser explotable, y voy a intentar establecer esa razón antes de intentar activarlo. Los candidatos que cerré antes de este incluían:

- rutas que parecían no sincronizadas pero estaban serializadas por un bloqueo adquirido un marco más arriba,
- rutas donde el objeto "liberado" en realidad estaba en caché, no liberado,
- rutas que eran genuinamente propensas a carreras pero no alcanzables desde ningún llamador que un usuario de bajo privilegio pudiera controlar.

Cada uno de esos es un hallazgo que *no* envié a MSRC. Ese es el punto. El rendimiento de un investigador no es cuántos candidatos genera — es lo rápido que puede matar los incorrectos para no seguirlos sosteniendo a las 2 AM.

**Las tres preguntas que mataron a la mayoría de los candidatos:**

1. **¿Alguien por encima de mí está sosteniendo un bloqueo?** Interprocedural, no local. La ausencia de un bloqueo en una función no significa nada.
2. **¿Puede un llamador sin privilegios alcanzar realmente ambos lados?** Una carrera entre dos rutas que requieren diferentes niveles de privilegio no es una carrera, es un experimento mental.
3. **¿Es la memoria liberada reclamable en una ventana que pueda influenciar?** Si el desmontaje se completa atómicamente a efectos prácticos, no hay ningún error que valga la pena reportar.

## 6. Verificación: la estática da hipótesis, el depurador da la verdad

El análisis estático de `win32kfull.sys` me dio la hipótesis. Nunca podría darme el error. **Las condiciones de carrera no son visibles en un descompilador** porque el defecto no está en las instrucciones — está en la intercalación.

### Laboratorio

| Rol | Configuración |
| --- | --- |
| Host / depurador | Windows 11, WinDbg |
| Objetivo | Windows Server 2022, Build 20348.2159 |
| Análisis | Kali Linux + VM de Windows 11 |
| Transporte de depuración | COM serial de VMware, depuración de kernel host → objetivo |
| Análisis estático | Ghidra vía GhidraMCP |
| Asistencia de triaje | Pasada asistida por IA sobre la salida descompilada |

Tres capas de instrumentación hicieron el trabajo real.

### Special pool y Driver Verifier

El paso de mayor apalancamiento en cualquier investigación de UAF en kernel. De forma predeterminada, la memoria del pool liberada se reutiliza casi inmediatamente por la siguiente asignación de tamaño similar — lo que significa que un use-after-free normalmente *no falla*. Lee datos válidos de otra persona, sigue ejecutándose y detona en algún lugar no relacionado minutos después. Entonces pasas tres días auditando una función inocente.

Special pool cambia eso. Cada asignación obtiene su propia página con una página de guarda adyacente, y las páginas liberadas se marcan como sin acceso en lugar de reciclarse. El resultado es que la desreferencia infractora falla **en la instrucción que la realiza**, no río abajo:```
!verifier 0x1 win32kfull.sys        ; special pool on the target driver
!verifier 0x8 win32kfull.sys        ; pool tracking

Un bloque que está *asignado* con una etiqueta plausible y contenido basura apunta hacia **corrupción**. Un bloque que está *liberado*, o que se encuentra en una página sin acceso de un pool especial, apunta hacia un **bug de tiempo de vida** — algo mantuvo un puntero después de la muerte del objeto. Esa es la distinción entre *'un atacante escribió aquí'* y *'este objeto no debería haber sido accesible,'* y es la diferencia entre un informe de corrupción del heap y un informe CWE-362.

Contrasta el tipo de objeto antes de comprometerte con cualquiera de los dos. Una `PWND` tiene una forma reconocible; si la memoria en la que se produjo el fallo todavía conserva los restos de una, casi con seguridad estás ante un problema de ventana de tiempo de vida, no ante una sobrescritura aleatoria.

### Depuración del kernel en vivo del intercalado

Incluso con el pool especial, una carrera es un problema de planificación, y **el depurador cambia la planificación.** Esa es la frustración central del trabajo con carreras: el instrumento perturba aquello que mide. Un punto de interrupción en la ruta de teardown serializa exactamente los dos hilos que intentas superponer, y el error desaparece cortésmente.

La forma de sortearlo es dejar de intentar atrapar la carrera con un punto de interrupción y, en su lugar:

- **ampliar la ventana artificialmente** — cualquier cosa que alargue el intervalo entre la liberación de la referencia y el teardown hace que la colisión sea alcanzable con tasas de planificación normales,
- **aumentar los intentos de colisión en lugar de la precisión** — ejecuta las dos rutas continuamente y deja que la probabilidad haga el trabajo,
- **usar puntos de interrupción condicionales y de un solo disparo** que solo se activen una vez que exista el estado interesante, en lugar de detenerse en cada entrada,
- **confirmar el intercalado después del fallo**, a partir del estado de los hilos y las pilas, en lugar de intentar observarlo en vivo.

El fallo en sí, una vez que lo tienes, es poco glamuroso — una desreferencia de un `PWND` en la ruta de despacho de mensajes donde el objeto ya ha pasado por el teardown en otro hilo, con `!pool` confirmando que el bloque fue liberado, no sobrescrito:```
kd> !analyze -v

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Access violation
FAULTING_MODULE: win32kfull