Ces deux jours, j’ai fait l’analyse de sécurité d’AEGIS pour @Dusk . Au début, je n’ai retenu que « 39 correctifs, 7 problèmes critiques ». En regardant les détails, je me suis rendu compte que les chiffres ne sont pas l’essentiel. À la fin, les 7 graves problèmes se sont rassemblés en 4 catégories de causes racines : des problèmes d’alias dans le bac à sable VM, une désérialisation non sécurisée côté hôte, l’insuffisante liaison entre les frais Phoenix et les remboursements, et des chemins de contrefaçon de signature BLS.
Pourquoi s’intéresser aux causes racines plutôt qu’à la seule liste des vulnérabilités ? Parce que si la même frontière de confiance n’est pas correctement définie, des problèmes repoussent encore et encore dans différents modules. Par exemple : désérialiser avant même d’avoir validé l’entrée, ce qui ressemble à une simple erreur d’analyse à première vue, mais peut en réalité mener à des failles de sécurité de mémoire côté hôte. Et la série de problèmes liés à Phoenix n’est pas « juste une petite erreur de calcul de frais » : c’est une absence d’alignement entre la preuve, la signature et l’exécution des remboursements au même niveau de sémantique ; au pire, cela peut toucher à l’intégrité de la fourniture et à la sécurité des fonds.
Officiellement, on dit qu’aucune exploitation de ces problèmes critiques n’a été observée avant leur correction. J’aimerais l’accepter comme conclusion d’enquête, sans pour autant la transformer en « absolument rien ne s’est produit ». Pour $DUSK , le signal positif d’AEGIS, c’est que l’équipe a rendu publiques les découvertes internes, ainsi que la logique des causes racines et des correctifs. Le signal négatif est tout aussi clair : après le déploiement sur le réseau principal, la pile critique a bien présenté des lacunes dangereuses capables d’affecter l’exécution, l’authentification de consensus et la disponibilité de la chaîne.
Donc je n’utiliserai pas « beaucoup d’audits » pour apposer un tampon de sécurité à #dusk . L’observation la plus utile, c’est plutôt : lors de la prochaine itération, y aura-t-il une poursuite de la divulgation ? Les tests de non-régression pour les frontières de même type seront-ils réalisés ? Et les audits externes pourront-ils couvrir le code après AEGIS ? Vous accordez plus d’importance au fait que le projet n’ait jamais révélé de gros problèmes, ou au fait qu’après les avoir révélés, l’équipe puisse expliquer clairement les causes racines, l’impact et la chaîne de correction ?
$USELESS $BOME
Pourquoi s’intéresser aux causes racines plutôt qu’à la seule liste des vulnérabilités ? Parce que si la même frontière de confiance n’est pas correctement définie, des problèmes repoussent encore et encore dans différents modules. Par exemple : désérialiser avant même d’avoir validé l’entrée, ce qui ressemble à une simple erreur d’analyse à première vue, mais peut en réalité mener à des failles de sécurité de mémoire côté hôte. Et la série de problèmes liés à Phoenix n’est pas « juste une petite erreur de calcul de frais » : c’est une absence d’alignement entre la preuve, la signature et l’exécution des remboursements au même niveau de sémantique ; au pire, cela peut toucher à l’intégrité de la fourniture et à la sécurité des fonds.
Officiellement, on dit qu’aucune exploitation de ces problèmes critiques n’a été observée avant leur correction. J’aimerais l’accepter comme conclusion d’enquête, sans pour autant la transformer en « absolument rien ne s’est produit ». Pour $DUSK , le signal positif d’AEGIS, c’est que l’équipe a rendu publiques les découvertes internes, ainsi que la logique des causes racines et des correctifs. Le signal négatif est tout aussi clair : après le déploiement sur le réseau principal, la pile critique a bien présenté des lacunes dangereuses capables d’affecter l’exécution, l’authentification de consensus et la disponibilité de la chaîne.
Donc je n’utiliserai pas « beaucoup d’audits » pour apposer un tampon de sécurité à #dusk . L’observation la plus utile, c’est plutôt : lors de la prochaine itération, y aura-t-il une poursuite de la divulgation ? Les tests de non-régression pour les frontières de même type seront-ils réalisés ? Et les audits externes pourront-ils couvrir le code après AEGIS ? Vous accordez plus d’importance au fait que le projet n’ait jamais révélé de gros problèmes, ou au fait qu’après les avoir révélés, l’équipe puisse expliquer clairement les causes racines, l’impact et la chaîne de correction ?
$USELESS $BOME
