Le format lui-même est un peu plus complexe et permet une sérialisation et une désérialisation plus élaborées, mais cela donne une compréhension de base de la vulnérabilité réelle.

Vulnérabilité

Jusqu'à ce commit³, lors de la traversée des chunks pour résoudre les références, par exemple pour obtenir fruitName à partir du chunk 2 dans l'exemple ci-dessus, React ne vérifiait pas si la clé demandée était réellement définie sur l'objet. Cela permettait d'obtenir le prototype de l'objet⁴.

Ceci peut être démontré avec une charge utile comme celle-ci :

Qui se désérialise en le constructeur de fonction⁵ :

Lorsque le chunk avec l'ID 0 n'est pas un tableau mais un objet, nous pouvons définir la clé then sur le constructeur de fonction. L'objet est ensuite renvoyé par la fonction decodeReplyFromBusboy et attendu (await) par Next.js :

Lorsque cela renvoie un thenable, le await chez l'appelant l'invoquera. C'est ce qui se passe avec cette charge utile :

Ce qui conduit à cette erreur :

L'erreur ressemble à ceci car V8 appelle une fonction awaitée avec les fonctions internes resolve et reject, qui, lorsqu'elles sont passées à toString, se sérialisent en quelque chose comme :

Exploitation

Puisque nous pouvons trivialement récupérer le constructeur Function, l'approche directe consiste à trouver un gadget d'appel qui invoque le constructeur avec une valeur contrôlée par l'utilisateur (c'est-à-dire le code de la fonction sous forme de chaîne de caractères), puis appelle ensuite la fonction renvoyée.

Il existe plusieurs endroits capables d'appeler le constructeur de fonction, par exemple resolveServerReference, où id est un objet contrôlé, et où lastIndexOf peut être redéfini pour renvoyer une chaîne contrôlée par l'utilisateur (par exemple via Array.prototype.join), et slice peut être redéfini sur le constructeur de fonction. Cependant, cet endroit ne fonctionne pas car la seconde invocation de .slice() fournit un nombre comme premier argument, ce qui, à ma connaissance, ne peut jamais être pris en charge par le constructeur de fonction.

C'est ici qu'intervient une idée brillante de maple3142⁶. Lorsque getChunk récupère le chunk à l'ID 0 comme référence racine pour commencer à résoudre la chaîne de références, ce même chunk peut se résoudre en un « faux chunk » fabriqué.

Nous pouvons référencer le chunk 0 fabriqué dans le chunk 1 en utilisant la syntaxe $@, qui renvoie le chunk « brut », et non sa valeur résolue :

En combinant cela avec notre redéfinition de then ci-dessus, nous pouvons fabriquer quelque chose comme :

Ici, le chunk 0 redéfinit son propre .then() avec le .then() de sa propre représentation de chunk brut. En termes simples, nous redéfinissons notre propre .then() avec Chunk.prototype.then, qui existe puisque les Chunk sont des thenables :

Avec la charge utile ci-dessus, Chunk.prototype.then est finalement appelé avec le chunk fabriqué ayant l'ID 0.

Comme montré ci-dessus, lorsque .status sur notre faux chunk est resolved_model :

Nous entrons dans initializeModelChunk. Ici, .value est analysé comme du JSON, puis les références sont résolues sur l'objet renvoyé, en utilisant le contexte « externe » de nos chunks avec les ID 0 et 1 :

À l'intérieur de cela, nous obtenons maintenant une seconde passe d'évaluation avec un peu plus de valeurs auxquelles nous avons accès car le contexte externe est déjà résolu.

Il y a un gadget d'appel dans le traitement des données blob avec le préfixe $B dans le protocole Flight :

En utilisant le champ spécial _response, nous contrôlons la propriété response du chunk fabriqué :

Avec cela, nous pouvons fabriquer un objet avec de fausses propriétés ._formData et ._prefix :

La propriété .reason doit être ajoutée pour éviter l'échec de l'invocation de toString dans `initializeModelChunk:

En faisant pointer ._formData vers le constructeur de fonction et ._prefix vers notre code, nous obtenons un gadget d'invocation pour le constructeur de fonction dans la désérialisation des blobs :

Notre fonction fabriquée est ensuite renvoyée par parseModelString comme méthode .then() du chunk fabriqué, laquelle est également attendue, car tout cela se déroule dans une chaîne unique de résolution de promesses. Ainsi, en renvoyant un thenable, notre fonction fabriquée est appelée. Cela constitue le gadget d'appel requis mentionné ci-dessus.

En rassemblant tout cela avec une véritable charge utile RCE, nous obtenons quelque chose comme :

Le bonus, qui rend cette vulnérabilité encore plus grave, est que tout cela se produit pendant la désérialisation, avant que l'action demandée ne soit d'abord validée dans getActionModIdOrError. Ainsi, il suffit de définir un en-tête tel que Next-Action: foo pour déclencher la vulnérabilité.

Correctif

L'utilisation des références de chunks pour obtenir des propriétés du prototype est corrigée par cette vérification :