BitsLab, filiale de TonBit, a découvert une faille critique dans le cœur de TON VM : explication détaillée de la cause fondamentale de la faille et des mesures d'atténuation.
Ce rapport analyse en détail les détails techniques, les causes fondamentales et les méthodes d'attaque possibles des vulnérabilités DoS principales présentes dans la Machine virtuelle TON, tout en présentant la solution efficace proposée par l'équipe TonBit.
Récemment, le système Machine virtuelle du réseau TON a bénéficié d'une importante mise à niveau de sécurité. L'équipe de sécurité de TonBit, une filiale de BitsLab, a réussi à découvrir et à aider à corriger une faille critique qui aurait pu entraîner une épuisement des ressources de la Machine virtuelle TON. Cette faille exploitait le mécanisme récursif de la Machine virtuelle lors du traitement des Continuations imbriquées, et aurait pu être exploitée par des contrats malveillants, entraînant des plantages système et une instabilité du réseau.
Si cette vulnérabilité est exploitée de manière malveillante, il est possible de mettre tous les nœuds de validation hors service sans avoir besoin de dépenser un TON, menaçant directement la disponibilité du réseau. Dans cet incident, TonBit a rapidement localisé la vulnérabilité grâce à ses excellentes capacités techniques, et a proposé une solution innovante en remplaçant la récursivité par l'itération en ajustant le mécanisme de contrôle interne de la machine virtuelle, offrant ainsi un environnement écologique plus sûr pour les utilisateurs de TON. L'équipe officielle de TON exprime ses remerciements spéciaux à TonBit pour sa contribution exceptionnelle à la sécurité de l'écosystème dans sa dernière annonce de mise à jour.
Dans le rapport de sécurité détaillé suivant, nous analyserons en profondeur les causes, les détails techniques et les solutions de cette vulnérabilité. Le rapport décrit en détail comment la vulnérabilité est exploitée en construisant une chaîne récursive d'épuisement des ressources en utilisant la profondeur d'exécution de Continuation et comment les contrats malveillants épuisent l'espace de la pile de l'hôte en étendant la pile d'appels. De plus, nous expliquerons comment l'équipe de TonBit a résolu ce problème en éliminant les défauts de conception de la chaîne récursive et en utilisant un mécanisme d'itération collaborative. Cette correction améliore non seulement la stabilité du réseau TON, mais fournit également une référence importante pour la sécurité sous-jacente de l'industrie de la blockchain.
Étude de cas: vulnérabilité DoS dans TON VM et mesures d'atténuation correspondantes
Introduction
Ce rapport décrit une vulnérabilité DoS (déni de service) dans la Machine virtuelle TON et les mesures d'atténuation prises pour résoudre ce problème. Cette vulnérabilité est due à la manière dont la Machine virtuelle gère les nids de Continuation lors de l'exécution du contrat. Cette vulnérabilité permet à un contrat malveillant de déclencher une récursion profonde lors de l'évaluation en créant des Continuations et en les imbriquant de manière spécifique, épuisant ainsi l'espace de la pile de l'hôte et entraînant l'arrêt de la Machine virtuelle. Pour atténuer ce problème, la Machine virtuelle a modifié la gestion des Continuations et du flux de contrôle. Désormais, la Machine virtuelle ne fait plus d'appels terminaux séquentiels via la chaîne de Continuation, mais itère activement la chaîne. Cette approche garantit l'utilisation constante de l'espace de la pile de l'hôte, empêchant ainsi les débordements de pile.
Vue d'ensemble
Selon la documentation officielle, TON VM est une Machine virtuelle basée sur la pile, utilisant le style de passage de continuation (CPS, Continuation-Passing Style) comme mécanisme de contrôle de flux, utilisé pour les processus internes et les smart contracts. Les registres de contrôle de flux sont accessibles aux contrats, ce qui offre une certaine flexibilité.
La théorie de la continuation dans TVM peut théoriquement être divisée en trois catégories:
OrdCont (c’est-à-dire vmc_std), qui contient le fragment TON ASM qui doit être exécuté, est un objet de premier niveau dans TVM. Les contrats peuvent les créer explicitement au moment de l’exécution et les transmettre pour implémenter des flux de contrôle arbitraires.
Les continuations extraordinaires (Extraordinary continuations), qui incluent généralement OrdCont en tant que composant, sont créées à l'aide de primitives d'itération explicites et d'opérations implicites spéciales pour gérer les mécanismes de flux de contrôle correspondants.
ArgContExt supplémentaire, encapsulant d'autres continuations pour conserver les données de contrôle.
Pendant l'exécution du contrat, la Machine virtuelle entre dans la boucle principale, décode un caractère à la fois du fragment de contrat et envoie l'opération correspondante au programme de traitement approprié. Le programme de traitement normal renvoie immédiatement après l'exécution de l'opération correspondante.
Relativement, l'instruction d'itération utilisera la Continuation fournie comme composant pour créer une Continuation non ordinaire et sauter à la Continuation non ordinaire dans le contexte approprié. La Continuation non ordinaire implémente la logique lors du saut et saute vers un composant en fonction de la condition. Par exemple, lors de l'utilisation de l'instruction WHILE, nous pouvons démontrer ce processus dans la Figure 1 (en omettant toute sortie potentielle).
Figure 1: Logique de continuation non ordinaire
Raison fondamentale
Dans les versions de Machine virtuelle vulnérables, ces sauts provoquent des appels de queue dynamiques continus, ce qui oblige la pile hôte à maintenir un frame de pile pour chaque saut (comme illustré dans la figure 2).
En prenant WhileCont comme exemple, d'autres parties sont omises pour des raisons de concision.
Figure 2: Triple jump recursion to dive into piège.
Idéalement, cela ne poserait pas de problème, car le composant est généralement représenté sous la forme d’un OrdCont dont le saut ne fait que sauvegarder le contexte courant et demande ensuite à la Machine virtuelle d’exécuter le fragment qu’elle contient, en s’exécutant avant les fragments de contrat restants, et n’introduit pas plus de récursivité. Cependant, les continuations non triviales sont théoriquement conçues pour permettre l’accès à leurs composants via le registre cc(c0) dans le TVM (c’est-à-dire la branche set_c0 ci-dessus). Par conséquent, les contrats peuvent abuser de cette fonctionnalité pour effectuer une récursivité de profondeur (décrite plus loin). Il est beaucoup plus clair et plus facile d’éliminer la récursivité directement lors d’un saut vers une continuation non normale que de modifier l’implémentation de cette fonctionnalité générale.
En construisant une Continuation non ordinaire de niveau supérieur en utilisant une Continuation non ordinaire déjà acquise à plusieurs reprises, il est possible de créer de manière itérative une Continuation imbriquée en profondeur. Lors de l'évaluation de ces Continuations imbriquées en profondeur, il est possible d'épuiser l'espace de pile disponible de l'hôte, ce qui entraîne l'émission d'un signal SIGSEGV par le système d'exploitation et la terminaison du processus Machine virtuelle.
La figure 3 fournit une validation conceptuelle (PoC) du processus de nesting.
Figure 3: Process d'encastrement du piège
Nous constatons que dans chaque itération, le corps se développe avec un WhileCont{chkcond=true}. En exécutant le cc généré et enregistré lors de la dernière itération, une pile d'appels similaire à celle-ci est obtenue :
On peut voir que l'espace de la pile est linéairement dépendant du niveau d'imbrication (c'est-à-dire du nombre d'itérations), ce qui indique qu'il peut conduire à l'épuisement de l'espace de la pile.
L'utilisation en environnement réel
Dans le Bloc réel, les frais de carburant limitent considérablement la construction de contrats malveillants. En raison de la complexité linéaire du processus d'enrobage (le TVM empêche efficacement la construction moins chère par auto-référence), le développement de contrats malveillants pratiquement réalisables n'est pas facile. En particulier, un enrobage de couche générera une séquence d'appels, consommant trois trames de pile hôte (320 octets) dans le fichier binaire de débogage, tandis qu'il en consommera deux (256 octets, les deux derniers appels étant en ligne) dans le fichier binaire publié. Pour un nœud de vérification fonctionnant sur un système d'exploitation POSIX moderne, la taille de la pile par défaut est de 8 MiB, ce qui est suffisant pour prendre en charge plus de 30 000 couches d'enrobage dans le fichier binaire publié. Bien qu'il soit toujours possible de construire un contrat qui épuise l'espace de la pile, cela est beaucoup plus difficile que l'exemple de la section précédente.
Mesures d'allègement
Ce correctif modifie le comportement du saut dans le cas de l'imbrication de Continuation. Nous pouvons voir que la signature du saut de Continuation a changé.
Pour prendre UntilCont comme exemple, le reste est omis pour des raisons de concision.
Ne pas appeler VmState::jump pour passer à la prochaine continuation, ce qui signifie que la triple saut est exécuté de manière récursive sur chaque continuation et attend que la valeur de retour soit propagée vers l'arrière. Maintenant, le saut de continuation ne résout que le niveau suivant de la continuation, puis renvoie le contrôle à la Machine virtuelle.
La Machine virtuelle itère de manière collaborative pour résoudre chaque niveau de continuation, jusqu'à ce qu'elle rencontre un NullRef, indiquant que la résolution de la chaîne est terminée (comme implémenté dans OrdCont ou ExuQuitCont). Au cours de cette itération, seule une transition de continuation est allouée sur la pile hôte, garantissant ainsi une utilisation constante de la pile.
Conclusion
Pour les services nécessitant une haute disponibilité, l'utilisation récursive peut devenir un Vecteur d'attaque potentiel. L'arrêt récursif forcé peut poser des défis lorsqu'il s'agit de logique définie par l'utilisateur. Cette vulnérabilité DOS montre un cas extrême où les fonctionnalités normales sont abusées de manière inattendue dans des conditions de ressources limitées (ou autres conditions limitées). Des problèmes similaires peuvent se produire si la récursivité dépend de l'entrée de l'utilisateur, ce qui est courant dans les primitives de flux de contrôle de la Machine virtuelle.
Ce rapport analyse en détail les détails techniques, les causes fondamentales et les modes d'attaque possibles des vulnérabilités DoS principales présentes dans la Machine virtuelle TON, tout en présentant une solution efficace proposée par l'équipe TonBit. En ajustant le mécanisme de saut récursif de la Machine virtuelle pour le traiter de manière itérative, TonBit a réussi à proposer une solution de correction des vulnérabilités, aidant ainsi à résoudre une vulnérabilité critique pouvant entraîner un effondrement du réseau, et offrant une sécurité plus robuste à l'écosystème TON. Cet événement démontre non seulement l'expertise approfondie de TonBit dans le domaine de la sécurité des technologies sous-jacentes à la blockchain, mais également son rôle important en tant que fournisseur officiel de garantie de sécurité (SAP) de TON.
En tant que partenaire de sécurité essentiel de l'écosystème TON, TonBit est toujours à la pointe de la protection de la stabilité du réseau Bloc et de la sécurité des actifs des utilisateurs. De la découverte de failles à la conception de solutions, TonBit a posé des bases solides pour le développement à long terme du réseau TON grâce à sa forte expertise technique et sa compréhension approfondie du développement Bloc. Parallèlement, l'équipe de TonBit continue de s'investir dans l'architecture de sécurité réseau, la protection des données des utilisateurs et l'amélioration de la sécurité des applications Bloc. À l'avenir, TonBit continuera à faire progresser la sécurité grâce à l'innovation, offrant un soutien continu à l'écosystème TON et garantissant le développement sain de l'ensemble de l'industrie Bloc. La découverte de cette faille et les travaux de réparation qui ont suivi ont été vivement approuvés par les autorités TON, renforçant davantage la position de TonBit dans le domaine de la sécurité Bloc et témoignant de son engagement ferme envers la promotion de la Décentralisation.
Site officiel de TonBit :
TonBit Twitter officiel :
Telegram:
Linkedin:
Blog : #blogs
Contactez @starchou pour les besoins d'audit de Telegram
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
BitsLab, filiale de TonBit, a découvert une faille critique dans le cœur de TON VM : explication détaillée de la cause fondamentale de la faille et des mesures d'atténuation.
Ce rapport analyse en détail les détails techniques, les causes fondamentales et les méthodes d'attaque possibles des vulnérabilités DoS principales présentes dans la Machine virtuelle TON, tout en présentant la solution efficace proposée par l'équipe TonBit.
Récemment, le système Machine virtuelle du réseau TON a bénéficié d'une importante mise à niveau de sécurité. L'équipe de sécurité de TonBit, une filiale de BitsLab, a réussi à découvrir et à aider à corriger une faille critique qui aurait pu entraîner une épuisement des ressources de la Machine virtuelle TON. Cette faille exploitait le mécanisme récursif de la Machine virtuelle lors du traitement des Continuations imbriquées, et aurait pu être exploitée par des contrats malveillants, entraînant des plantages système et une instabilité du réseau.
Si cette vulnérabilité est exploitée de manière malveillante, il est possible de mettre tous les nœuds de validation hors service sans avoir besoin de dépenser un TON, menaçant directement la disponibilité du réseau. Dans cet incident, TonBit a rapidement localisé la vulnérabilité grâce à ses excellentes capacités techniques, et a proposé une solution innovante en remplaçant la récursivité par l'itération en ajustant le mécanisme de contrôle interne de la machine virtuelle, offrant ainsi un environnement écologique plus sûr pour les utilisateurs de TON. L'équipe officielle de TON exprime ses remerciements spéciaux à TonBit pour sa contribution exceptionnelle à la sécurité de l'écosystème dans sa dernière annonce de mise à jour.
Dans le rapport de sécurité détaillé suivant, nous analyserons en profondeur les causes, les détails techniques et les solutions de cette vulnérabilité. Le rapport décrit en détail comment la vulnérabilité est exploitée en construisant une chaîne récursive d'épuisement des ressources en utilisant la profondeur d'exécution de Continuation et comment les contrats malveillants épuisent l'espace de la pile de l'hôte en étendant la pile d'appels. De plus, nous expliquerons comment l'équipe de TonBit a résolu ce problème en éliminant les défauts de conception de la chaîne récursive et en utilisant un mécanisme d'itération collaborative. Cette correction améliore non seulement la stabilité du réseau TON, mais fournit également une référence importante pour la sécurité sous-jacente de l'industrie de la blockchain.
Étude de cas: vulnérabilité DoS dans TON VM et mesures d'atténuation correspondantes
Introduction
Ce rapport décrit une vulnérabilité DoS (déni de service) dans la Machine virtuelle TON et les mesures d'atténuation prises pour résoudre ce problème. Cette vulnérabilité est due à la manière dont la Machine virtuelle gère les nids de Continuation lors de l'exécution du contrat. Cette vulnérabilité permet à un contrat malveillant de déclencher une récursion profonde lors de l'évaluation en créant des Continuations et en les imbriquant de manière spécifique, épuisant ainsi l'espace de la pile de l'hôte et entraînant l'arrêt de la Machine virtuelle. Pour atténuer ce problème, la Machine virtuelle a modifié la gestion des Continuations et du flux de contrôle. Désormais, la Machine virtuelle ne fait plus d'appels terminaux séquentiels via la chaîne de Continuation, mais itère activement la chaîne. Cette approche garantit l'utilisation constante de l'espace de la pile de l'hôte, empêchant ainsi les débordements de pile.
Vue d'ensemble
Selon la documentation officielle, TON VM est une Machine virtuelle basée sur la pile, utilisant le style de passage de continuation (CPS, Continuation-Passing Style) comme mécanisme de contrôle de flux, utilisé pour les processus internes et les smart contracts. Les registres de contrôle de flux sont accessibles aux contrats, ce qui offre une certaine flexibilité.
La théorie de la continuation dans TVM peut théoriquement être divisée en trois catégories:
OrdCont (c’est-à-dire vmc_std), qui contient le fragment TON ASM qui doit être exécuté, est un objet de premier niveau dans TVM. Les contrats peuvent les créer explicitement au moment de l’exécution et les transmettre pour implémenter des flux de contrôle arbitraires.
Les continuations extraordinaires (Extraordinary continuations), qui incluent généralement OrdCont en tant que composant, sont créées à l'aide de primitives d'itération explicites et d'opérations implicites spéciales pour gérer les mécanismes de flux de contrôle correspondants.
ArgContExt supplémentaire, encapsulant d'autres continuations pour conserver les données de contrôle.
Pendant l'exécution du contrat, la Machine virtuelle entre dans la boucle principale, décode un caractère à la fois du fragment de contrat et envoie l'opération correspondante au programme de traitement approprié. Le programme de traitement normal renvoie immédiatement après l'exécution de l'opération correspondante.
Relativement, l'instruction d'itération utilisera la Continuation fournie comme composant pour créer une Continuation non ordinaire et sauter à la Continuation non ordinaire dans le contexte approprié. La Continuation non ordinaire implémente la logique lors du saut et saute vers un composant en fonction de la condition. Par exemple, lors de l'utilisation de l'instruction WHILE, nous pouvons démontrer ce processus dans la Figure 1 (en omettant toute sortie potentielle).
Figure 1: Logique de continuation non ordinaire
Raison fondamentale
Dans les versions de Machine virtuelle vulnérables, ces sauts provoquent des appels de queue dynamiques continus, ce qui oblige la pile hôte à maintenir un frame de pile pour chaque saut (comme illustré dans la figure 2).
En prenant WhileCont comme exemple, d'autres parties sont omises pour des raisons de concision.
Figure 2: Triple jump recursion to dive into piège.
Idéalement, cela ne poserait pas de problème, car le composant est généralement représenté sous la forme d’un OrdCont dont le saut ne fait que sauvegarder le contexte courant et demande ensuite à la Machine virtuelle d’exécuter le fragment qu’elle contient, en s’exécutant avant les fragments de contrat restants, et n’introduit pas plus de récursivité. Cependant, les continuations non triviales sont théoriquement conçues pour permettre l’accès à leurs composants via le registre cc(c0) dans le TVM (c’est-à-dire la branche set_c0 ci-dessus). Par conséquent, les contrats peuvent abuser de cette fonctionnalité pour effectuer une récursivité de profondeur (décrite plus loin). Il est beaucoup plus clair et plus facile d’éliminer la récursivité directement lors d’un saut vers une continuation non normale que de modifier l’implémentation de cette fonctionnalité générale.
En construisant une Continuation non ordinaire de niveau supérieur en utilisant une Continuation non ordinaire déjà acquise à plusieurs reprises, il est possible de créer de manière itérative une Continuation imbriquée en profondeur. Lors de l'évaluation de ces Continuations imbriquées en profondeur, il est possible d'épuiser l'espace de pile disponible de l'hôte, ce qui entraîne l'émission d'un signal SIGSEGV par le système d'exploitation et la terminaison du processus Machine virtuelle.
La figure 3 fournit une validation conceptuelle (PoC) du processus de nesting.
Figure 3: Process d'encastrement du piège
Nous constatons que dans chaque itération, le corps se développe avec un WhileCont{chkcond=true}. En exécutant le cc généré et enregistré lors de la dernière itération, une pile d'appels similaire à celle-ci est obtenue :
On peut voir que l'espace de la pile est linéairement dépendant du niveau d'imbrication (c'est-à-dire du nombre d'itérations), ce qui indique qu'il peut conduire à l'épuisement de l'espace de la pile.
L'utilisation en environnement réel
Dans le Bloc réel, les frais de carburant limitent considérablement la construction de contrats malveillants. En raison de la complexité linéaire du processus d'enrobage (le TVM empêche efficacement la construction moins chère par auto-référence), le développement de contrats malveillants pratiquement réalisables n'est pas facile. En particulier, un enrobage de couche générera une séquence d'appels, consommant trois trames de pile hôte (320 octets) dans le fichier binaire de débogage, tandis qu'il en consommera deux (256 octets, les deux derniers appels étant en ligne) dans le fichier binaire publié. Pour un nœud de vérification fonctionnant sur un système d'exploitation POSIX moderne, la taille de la pile par défaut est de 8 MiB, ce qui est suffisant pour prendre en charge plus de 30 000 couches d'enrobage dans le fichier binaire publié. Bien qu'il soit toujours possible de construire un contrat qui épuise l'espace de la pile, cela est beaucoup plus difficile que l'exemple de la section précédente.
Mesures d'allègement
Ce correctif modifie le comportement du saut dans le cas de l'imbrication de Continuation. Nous pouvons voir que la signature du saut de Continuation a changé.
Pour prendre UntilCont comme exemple, le reste est omis pour des raisons de concision.
Ne pas appeler VmState::jump pour passer à la prochaine continuation, ce qui signifie que la triple saut est exécuté de manière récursive sur chaque continuation et attend que la valeur de retour soit propagée vers l'arrière. Maintenant, le saut de continuation ne résout que le niveau suivant de la continuation, puis renvoie le contrôle à la Machine virtuelle.
La Machine virtuelle itère de manière collaborative pour résoudre chaque niveau de continuation, jusqu'à ce qu'elle rencontre un NullRef, indiquant que la résolution de la chaîne est terminée (comme implémenté dans OrdCont ou ExuQuitCont). Au cours de cette itération, seule une transition de continuation est allouée sur la pile hôte, garantissant ainsi une utilisation constante de la pile.
Conclusion
Pour les services nécessitant une haute disponibilité, l'utilisation récursive peut devenir un Vecteur d'attaque potentiel. L'arrêt récursif forcé peut poser des défis lorsqu'il s'agit de logique définie par l'utilisateur. Cette vulnérabilité DOS montre un cas extrême où les fonctionnalités normales sont abusées de manière inattendue dans des conditions de ressources limitées (ou autres conditions limitées). Des problèmes similaires peuvent se produire si la récursivité dépend de l'entrée de l'utilisateur, ce qui est courant dans les primitives de flux de contrôle de la Machine virtuelle.
Ce rapport analyse en détail les détails techniques, les causes fondamentales et les modes d'attaque possibles des vulnérabilités DoS principales présentes dans la Machine virtuelle TON, tout en présentant une solution efficace proposée par l'équipe TonBit. En ajustant le mécanisme de saut récursif de la Machine virtuelle pour le traiter de manière itérative, TonBit a réussi à proposer une solution de correction des vulnérabilités, aidant ainsi à résoudre une vulnérabilité critique pouvant entraîner un effondrement du réseau, et offrant une sécurité plus robuste à l'écosystème TON. Cet événement démontre non seulement l'expertise approfondie de TonBit dans le domaine de la sécurité des technologies sous-jacentes à la blockchain, mais également son rôle important en tant que fournisseur officiel de garantie de sécurité (SAP) de TON.
En tant que partenaire de sécurité essentiel de l'écosystème TON, TonBit est toujours à la pointe de la protection de la stabilité du réseau Bloc et de la sécurité des actifs des utilisateurs. De la découverte de failles à la conception de solutions, TonBit a posé des bases solides pour le développement à long terme du réseau TON grâce à sa forte expertise technique et sa compréhension approfondie du développement Bloc. Parallèlement, l'équipe de TonBit continue de s'investir dans l'architecture de sécurité réseau, la protection des données des utilisateurs et l'amélioration de la sécurité des applications Bloc. À l'avenir, TonBit continuera à faire progresser la sécurité grâce à l'innovation, offrant un soutien continu à l'écosystème TON et garantissant le développement sain de l'ensemble de l'industrie Bloc. La découverte de cette faille et les travaux de réparation qui ont suivi ont été vivement approuvés par les autorités TON, renforçant davantage la position de TonBit dans le domaine de la sécurité Bloc et témoignant de son engagement ferme envers la promotion de la Décentralisation.
Site officiel de TonBit :
TonBit Twitter officiel :
Telegram:
Linkedin:
Blog : #blogs
Contactez @starchou pour les besoins d'audit de Telegram