- Polygon a révélé des vulnérabilités affectant à la fois Bor et Heimdall après le déploiement des correctifs.
- Austin a fermé deux chemins de déni de service dans le traitement des blocs Polygon PoS.
- Kyoto a abordé un ensemble plus large de faiblesses en matière de consensus et de validation des intrants.
- Les nœuds obsolètes sont déjà en dehors du consensus canonique et doivent être mis à niveau.
Polygon Labs a divulgué des vulnérabilités auparavant privées dans son réseau Proof-of-Stake après que des correctifs aient déjà été déployés via les hard forks d'Austin et de Kyoto. Les problèmes allaient des chemins de déni de service dans le client d'exécution Bor à une attaque de transaction contrefaite capable d'imposer un traitement coûteux aux validateurs Heimdall. Polygon a déclaré n'avoir observé aucune exploitation sur le réseau principal.
Ce qui est plus remarquable que la divulgation elle-même est son timing. Polygon a délibérément caché les détails techniques pendant que les correctifs étaient distribués et testés en privé, réduisant ainsi la période pendant laquelle les attaquants pouvaient étudier une vulnérabilité connue pendant que les validateurs restaient exposés.
Polygone corrigé en premier et divulgué ultérieurement
Les vulnérabilités du consensus créent un problème de divulgation difficile.
Publier des détails techniques trop tôt peut effectivement donner des instructions aux attaquants avant qu'un nombre suffisant d'opérateurs de nœuds n'aient installé le correctif. Cependant, attendre trop longtemps réduit la transparence sur les risques affectant le réseau.
Polygon a choisi une approche axée sur les correctifs.
Selon son examen de sécurité du 27 août, les modifications d'Austin et de Kyoto ont été initialement déployées en privé et validées sur le réseau de test Amoy avant l'activation du réseau principal. Les détails ont été publiés une fois que le réseau est passé aux versions corrigées.
Cette séquence est importante car les vulnérabilités n’étaient pas simplement des bogues logiciels théoriques. Plusieurs d’entre eux auraient pu dégrader la disponibilité du réseau s’ils étaient délibérément déclenchés.
Polygon a néanmoins signalé que ni les problèmes de déni de service d'Austin ni les vulnérabilités de Kyoto n'avaient été exploités sur le réseau principal avant d'être corrigés.
Austin a fermé deux voies d'épuisement des ressources
Le hard fork d'Austin a amélioré celui de Polygon Client d'exécution Bor vers v2.10.0 et s'est concentré sur deux vecteurs de déni de service dans le traitement des blocs.
L'un d'entre eux impliquait le mécanisme de synchronisation d'état de Polygon, qui transporte des événements d'Ethereum au Polygon PoS.
Ces opérations peuvent exécuter des contrats et des précompilations de la même manière que les transactions ordinaires, mais leur consommation de ressources n'était pas suffisamment limitée au niveau des blocs. Une charge de travail de synchronisation d’état suffisamment coûteuse pourrait donc exercer une pression de calcul excessive sur les nœuds et potentiellement bloquer le traitement des blocs.
Austin a introduit une limite de gaz par bloc pour les opérations de synchronisation d'état, plafonnant ainsi la quantité de traitement qu'elles peuvent consommer.
La deuxième faiblesse concernait le champ TxDependency de Bor.
Étant donné que la structure des données n'avait pas de limite de taille stricte, une entrée surdimensionnée de manière malveillante pouvait consommer des ressources excessives lors de sa réception ou de son décodage, ce qui risquait de bloquer le traitement ou de faire planter les homologues connectés.
Austin a supprimé le champ illimité.
Aucune des deux vulnérabilités ne représentait un mécanisme de vol direct. Le principal risque était la disponibilité, un attaquant pouvant dégrader la capacité des nœuds à traiter les blocs de manière fiable.
Kyoto a abordé le risque plus grave du validateur
Le hard fork de Kyoto, implémenté via Heimdall v0.11.0traitait d'un ensemble plus large de problèmes affectant le traitement du consensus, les points de contrôle, les jalons et la validation des entrées.
Polygon a identifié les messages google.protobuf.Any profondément imbriqués comme le problème le plus grave du lot.
Les transactions Heimdall peuvent envelopper des messages dans des structures Any, qui elles-mêmes peuvent contenir des messages Any supplémentaires. Sans limite de profondeur, un attaquant pourrait construire une transaction relativement peu coûteuse à soumettre mais coûteuse en termes de calcul pour les validateurs à décoder.
C’est l’asymétrie qui rend le défaut dangereux.
Une transaction contrefaite pourrait obliger de nombreux validateurs à effectuer simultanément le même traitement coûteux.
Kyoto a introduit une pré-analyse au niveau des octets qui rejette les transactions une fois que l'imbrication des messages dépasse le seuil autorisé. Fondamentalement, Polygon applique la même règle à la fois à l'admission du pool de mémoire et à l'étape de traitement du consensus, empêchant différentes parties du réseau de traiter différemment la même transaction.
Le fork a également plafonné les listes de pièces payantes pour empêcher une analyse linéaire excessive et les octets de récupération de signature de point de contrôle standardisés pour réduire le risque de problèmes d'ancrage de point de contrôle sur Ethereum.
D'autres correctifs ont renforcé la comptabilité des jalons et le comportement de relecture des événements L1.
Pourquoi l'épuisement des ressources peut menacer une blockchain sans voler de fonds
Les vulnérabilités mettent en évidence une catégorie différente de risque de sécurité blockchain par rapport aux exploits qui font généralement la une des journaux sur la cryptographie.
Un exploit de contrat intelligent peut permettre à un attaquant de drainer directement les actifs. Les attaques par épuisement des ressources ciblent plutôt la capacité du réseau à continuer à traiter les transactions et à parvenir à un consensus.
Les aspects économiques peuvent être particulièrement problématiques lorsqu'il existe une grande asymétrie entre le coût de l'attaquant et celui du réseau.
Si un attaquant peut créer à moindre coût une entrée qui nécessite que chaque validateur effectue un calcul substantiel, le coût est multiplié par l'ensemble de l'ensemble des validateurs. La répétition de ce processus peut ralentir le traitement des blocs, augmenter la consommation des ressources des nœuds ou, dans les cas graves, interférer avec la vivacité du réseau.
Les correctifs de Polygon se concentrent donc fortement sur l'introduction de limites : limites sur la consommation de gaz, la profondeur des messages et la taille des listes.
Ces restrictions rendent plus prévisible le coût de calcul du traitement des données contrôlées par les attaquants.
Les anciens nœuds sont déjà en dehors du consensus canonique
Pour les opérateurs de nœuds, la divulgation n'est plus simplement un avis sur les futures mises à niveau.
Les deux hard forks sont déjà actifs.
Polygon indique que les nœuds qui sont restés sur les versions antérieures au-delà des hauteurs d'activation pertinentes se sont déjà éloignés du réseau canonique.
Les opérateurs peuvent récupérer en installant des binaires compatibles, en revenant à la hauteur de pré-fork appropriée et en permettant au nœud de se resynchroniser.
Les mises à niveau ne nécessitent pas de changement de genèse, de migration d'état ou de resynchronisation complète, ce qui réduit la charge opérationnelle pour les opérateurs concernés.
Polygon a depuis publié Bor v2.10.1, bien que la v2.10.0 reste la version minimale compatible avec Austin.
La divulgation modifie le risque pour les nœuds qui n'ont toujours pas été mis à niveau
La divulgation retardée de Polygon a réduit l'exposition pendant la migration du réseau, mais la publication modifie désormais l'environnement de sécurité.
Les mécanismes techniques derrière les vulnérabilités sont publics. Ce n'est pas une préoccupation majeure pour les nœuds exécutant déjà des logiciels compatibles Austin et Kyoto, car les voies d'attaque concernées ont été fermées.
Cela a plus de conséquences pour les opérateurs qui exécutent encore des binaires obsolètes.
Avant la divulgation, un nœud obsolète était principalement confronté à un problème de compatibilité. Il utilise désormais un logiciel présentant des failles de sécurité publiquement documentées, tout en restant en dehors du consensus canonique.
Cela rend la mise à niveau plus urgente même si Polygon n'a signalé aucune exploitation historique du réseau principal.
L'épisode fournit également une mesure utile du processus de sécurité de Polygon, au-delà de la perte de fonds. Austin et Kyoto montrent le réseau utilisant des mises à niveau client coordonnées pour corriger les vulnérabilités avant de publier suffisamment de détails pour qu'elles puissent être reproduites.
La prochaine mesure opérationnelle est donc simple : la rapidité avec laquelle l’infrastructure obsolète restante disparaît maintenant que les correctifs et les vecteurs d’attaque sous-jacents sont publics.