
Polygon révèle des failles DoS corrigées, avertit des…
Les hard forks d'Austin et de Kyoto ont expédié les correctifs avant leur divulgation, et Polygon annonce que Bor v2.10.0 et Heimdall v0.11.0 sont désormais obligatoires.
Polygon Labs a divulgué des vulnérabilités précédemment privées dans les clients PoS de Polygon, Bor et Heimdall, après avoir déployé des correctifs via les hard forks Austin et Kyoto. Polygon a déclaré qu'aucune exploitation sur le mainnet n'avait été observée, mais a averti que les nœuds utilisant des versions de clients plus anciennes sont déjà hors consensus et doivent mettre à jour pour rejoindre la chaîne canonique.
Polygon révèle des failles corrigées de Bor/Heimdall après les hard forks d'Austin et de Kyoto.
PolygoneL'équipe de support des validateurs de Labs a publié une divulgation de sécurité décrivant plusieurs vulnérabilités dans Polygon PoS qui ont été corrigées grâce aux hard forks d'Austin et de Kyoto, les détails techniques n'ayant été publiés qu'après que les corrections aient déjà été actives sur le mainnet.
Les problèmes concernent les deux clients principaux de Polygon PoS : Bor, le client de la couche d'exécution responsable de la production et du traitement des blocs, et Heimdall, le composant orienté vers les validateurs lié aux opérations de consensus ainsi qu'à la gestion des points de contrôle et des jalons.
Polygon a décrit cet ensemble comme incluant des risques de déni de service, l'épuisement des ressources des validateurs et des défauts affectant le traitement des points de contrôle et des jalons.
Le problème le plus grave décrit se situe du côté de Heimdall. Polygon a déclaré qu'une transaction spécialement conçue pourrait forcer les validateurs à effectuer un travail de traitement excessif, un schéma classique d'épuisement des ressources des validateurs qui peut se traduire par une dégradation des performances ou de la disponibilité plutôt que par un impact direct.actifperte.
Austin a également abordé deux vecteurs de déni de service distincts dans Bor. Polygon a déclaré que ces problèmes de Bor auraient pu ralentir le traitement des blocs ou provoquer des pannes de nœuds, ce qui est le type de mode de défaillance que les traders ressentent comme une congestion, une finalité retardée et une exécution peu fiable pendant des périodes de volatilité.
Le cadre de Polygon est explicitement post-fix. La divulgation indique, textuellement, « Aucune des vulnérabilités n'a été observée comme étant exploitée sur le mainnet », et précise que les hard forks ont été « déployés en privé et testés » avant l'activation du mainnet. Le document n'inclut pas la chronologie ou l'étendue du déploiement privé, et il ne fournit pas les hauteurs ou dates d'activation d'Austin et de Kyoto.
Comment je traderais la divulgation : incident contenu, mais attention à la friction de mise à niveau
L'application de la mise à niveau est en cours : versions clients requises et risque de perte de consensus
Polygon a associé la divulgation à un avertissement opérationnel qui compte plus pour la stabilité à court terme de la chaîne que la rédaction de la vulnérabilité elle-même. L'équipe a écrit : « Les nœuds exécutant des versions plus anciennes de l'un ou l'autre client après les hauteurs d'activation du hard fork ont déjà perdu le consensus et doivent mettre à niveau pour rejoindre le réseau canonique. »
Cette ligne a un véritable impact. Un hard fork change les règles de consensus, donc les nœuds qui ne se mettent pas à jour cessent d'être d'accord sur l'état valide de la chaîne et ne peuvent pas suivre la chaîne canonique. Pour les opérateurs, « hors consensus » n'est pas un avertissement léger. C'est une partition fonctionnelle du réseau jusqu'à ce que le client soit mis à niveau.
Polygon a également rendu explicites les versions requises : « Bor v2.10.0 est requis pour tous les nœuds Polygon PoS, tandis que Heimdall v0.11.0 est requis pour les validateurs et les nœuds complets », avec les deux mises à niveau déjà actives sur le mainnet. La variable à long terme n'est pas de savoir si le correctif existe.
C'est de savoir si la longue traîne de validateurs et de fournisseurs d'infrastructure a terminé la mise à niveau proprement, ou si les retardataires créent une instabilité de courte durée en se déconnectant et en se reconnectant.
Trois choses restent non résolues dans la divulgation telle qu'elle a été publiée. Premièrement, les hauteurs et dates d'activation exactes ne sont pas fournies, ce qui rend plus difficile pour les tiers de cartographier « au-delà des hauteurs d'activation » à une fenêtre de risque spécifique. Deuxièmement, la divulgation fait référence à la gravité de manière qualitative mais ne quantifie pas l'impact attendu dans des conditions d'attaque.
Troisièmement, il n'y a pas de confirmation indépendante dans le paquet au-delà de la déclaration de Polygon selon laquelle l'exploitation n'a pas été observée.
Le contexte du marché est atténué mais pertinent. POL (le jeton natif de Polygon, anciennement MATIC) se négociait autour de 0,10 $ au moment de la rédaction, en baisse d'environ 4 % au cours de la semaine passée, en hausse de 44 % au cours du mois dernier, et en hausse de 2,3 % depuis le début de l'année, selon les données de CoinGecko.
À ce niveau, la divulgation ressemble plus à un contrôle de sentiment sur la fiabilité de Polygon PoS qu'à un catalyseur autonome, à moins que le récit ne passe de « corrigé » à « perturbation active ».
Comment je lis le correctif des hard forks de Polygon PoS DoS
La divulgation est lue comme un rapport d'incident, et le détail procédural va dans l'autre sens. Polygon dit que les correctifs ont déjà été expédiés via Austin et Kyoto avant que la rédaction ne soit rendue publique, et il dit aussi « Aucune des vulnérabilités n'a été observée comme étant exploitée sur le mainnet », ce qui rend cela plus proche d'un post-mortem plus d'un avis opérationnel que d'une situation d'exploitation active.
Le seuil qui compte est l'achèvement de la mise à niveau, pas la taxonomie des vulnérabilités. Si Bor v2.10.0 et Heimdall v0.11.0 sont largement déployés sans qu'une vague de nœuds ait besoin de « rejoindre le réseau canonique », la divulgation reste contenue et principalement axée sur le récit.
Si la friction de mise à niveau commence à se manifester sous forme de problèmes de performance des validateurs ou de dégradation de la disponibilité, alors l'histoire cesse d'être celle d'un vecteur DoS corrigé et devient celle de savoir si Polygon PoS peut appliquer les mises à niveau des hard forks sans échanger la fiabilité contre l'hygiène de la sécurité.