Zero Day Initiative – Exploitation régulière d'un Tesla Model 3 via Chromium RegExp

123

Vous voyez le problème? Dans Runtime_RegExpReplaceRT il y a un chèque, IsUnmodifiedRegExp. Cela détermine si le RegExp l'objet est dans un état vierge et non modifié. Si tel est le cas, il peut tirer parti du code «fast path» implémenté dans RegExpReplace. Le problème est, peu de temps après être entré RegExpReplace, le code appelle Object::ToString pour effectuer une coercition sur la valeur spécifiée dans le deuxième argument de RegExp.prototype(@@replace). Cela permet à JavaScript arbitraire de s'exécuter. Le JavaScript modifie le RegExp afin qu'il ne soit plus considéré comme un objet JavaScript «non modifié» pouvant être correctement géré par le raccourci. En particulier, il définit lastIndex propriété d'être une coutume Object. Plus tard dans l'implémentation du raccourci, la valeur trouvée dans lastIndex sera contraint, ce qui entraînera un deuxième cycle d'exécution JavaScript inattendue. Ce JavaScript ajoute une nouvelle propriété (x) à l'objet d'expression régulière, modifiant ainsi la disposition de la mémoire de l'objet d'expression régulière et brisant les hypothèses formulées par le code d'accès rapide.

Attention, ne soyez pas dérouté par le commentaire qui précède l'appel à RegExpReplace. D'après le libellé du commentaire, on pourrait initialement penser que RegExpReplace n'est pas destiné au cas des non modifiés RegExp objets. Cependant, en examinant le contexte, il devient clair que le véritable objectif du commentaire est que RegExpReplace ne doit pas être appelée lorsqu'une fonction appelable est fournie comme argument de remplacement («remplaçant fonctionnel»), même si RegExp n'est pas modifié. Indépendamment, RegExpReplace est la voie rapide, et est destiné exclusivement au cas de non modifié RegExp objets.

Voyons maintenant comment cela a été corrigé, que vous pouvez voir ici. Nous sommes toujours intéressés à regarder src/runtime/runtime-regexp.cc:

Source