El formato en sí es un poco más intrincado y permite una serialización y deserialización más complejas, pero esto proporciona una comprensión básica para la vulnerabilidad real.

Vulnerabilidad

Hasta este commit³, al recorrer los chunks en la resolución de referencias, como obtener fruitName del chunk 2 en el ejemplo anterior, React no verificaba si la clave solicitada estaba realmente establecida en el objeto. Esto nos permitía obtener el prototipo del objeto⁴.

Esto se puede demostrar con un payload como este:

Que se deserializa en el constructor de funciones⁵:

Cuando el chunk con ID 0 no es un array sino un objeto, podemos establecer la clave then al constructor de funciones. El objeto es entonces devuelto por la función decodeReplyFromBusboy y await por Next.js:

Cuando esto devuelve un thenable, el await en el llamador lo ejecutará. Esto es lo que sucede con este payload:

Lo que lleva a este error:

El error se ve así porque V8 llama a una función awaiteada con las funciones internas resolve y reject, las cuales, cuando se les aplica toString, se serializan a algo como esto:

Explotación

Dado que podemos recuperar trivialmente el constructor Function, la forma más directa es encontrar un gadget de llamada que invoque al constructor con un valor controlado por el usuario (es decir, el código de la función como una cadena), y luego llame a la función devuelta.

Hay varios lugares que pueden llamar al constructor de funciones, por ejemplo resolveServerReference, donde id es un objeto controlado, y lastIndexOf puede sobrescribirse para devolver una cadena controlada por el usuario (por ejemplo, mediante Array.prototype.join) y slice puede sobrescribirse con el constructor de funciones. Sin embargo, este lugar no funciona porque la segunda invocación de .slice() proporciona un número como primer argumento, el cual, hasta donde sé, nunca puede ser manejado por el constructor de funciones.

Aquí entra una idea brillante de maple3142⁶. Cuando getChunk toma el chunk con ID 0 como referencia raíz para comenzar a resolver la cadena de referencias, este mismo chunk puede resolverse a un "falso chunk" manipulado.

Podemos referenciar el chunk manipulado 0 en el chunk 1 usando la sintaxis $@, que devuelve el chunk "crudo", no su valor resuelto:

Combinando esto con nuestra sobrescritura de then de arriba, podemos construir algo como esto:

Aquí, el chunk 0 sobrescribe su propio .then() con el .then() de su propia representación de chunk crudo. En términos simples, sobrescribimos nuestro propio .then() con Chunk.prototype.then, que existe, ya que los Chunks son thenables:

Con el payload anterior, Chunk.prototype.then es eventualmente llamado con el chunk manipulado con ID 0.

Como se muestra arriba, cuando .status en nuestro chunk falso es resolved_model:

Entramos en initializeModelChunk. Aquí, .value se analiza como JSON, y luego se resuelven las referencias sobre el objeto devuelto, usando el contexto "externo" de nuestros chunks con IDs 0 y 1:

Dentro de esto, ahora obtenemos una segunda pasada de evaluación con algunos valores más a los que tenemos acceso debido a que el contexto externo ya ha sido resuelto.

Hay un gadget de llamada en el manejo de datos blob con el prefijo $B en el protocolo flight:

Usando el campo especial _response, controlamos la propiedad response del chunk manipulado:

Con esto, podemos construir un objeto con propiedades falsas ._formData y ._prefix:

Es necesario agregar .reason para evitar fallar en la invocación de toString en initializeModelChunk:

Al apuntar ._formData al constructor de funciones, y ._prefix a nuestro código, obtenemos un gadget de invocación para el constructor de funciones en la deserialización de blob:

Nuestra función manipulada es entonces devuelta por parseModelString como el método .then() del chunk manipulado, el cual también es await, ya que todo esto tiene lugar en una única cadena de resolución de promesas. Así, al devolver un thenable, nuestra función manipulada es llamada. Esto constituye el gadget de llamada requerido mencionado anteriormente.

Juntando todo esto con un payload real de RCE, obtenemos algo como esto:

El extra, que hace que esta vulnerabilidad sea aún peor, es que todo esto ocurre durante la deserialización, antes de que la acción solicitada sea validada por primera vez en getActionModIdOrError. Por lo tanto, establecer un encabezado como Next-Action: foo es suficiente para desencadenar la vulnerabilidad.

Parche

El uso de las referencias a chunks para recuperar propiedades del prototipo se corrige con esta comprobación: