Bienvenue de nouveau dans le Spotlight sur les Vulnérabilités de Sherlock, où nous mettons en lumière une vulnérabilité impactante découverte lors d'un audit de Sherlock.
Cette semaine, nous examinons une attaque par déni de service trouvée dans le concours @GMX_IO par @0xdeadbeef____ et @IllIllI000.
Crédit à @int0x1catedCode pour l'analyse.
Résumé de la vulnérabilité :
La vulnérabilité permet à un attaquant de manipuler le flux d'exécution des ordres en fournissant de fausses longueurs de raison de retour qui ne correspondent pas aux données réelles. Cela amène le traitement des erreurs du protocole à lire des régions de mémoire incorrectes, perturbant potentiellement le processus d'exécution ou provoquant un comportement inattendu lors du traitement des ordres échoués.
Étapes de l'attaque :
1. Phase de configuration
Déployer un contrat malveillant qui implémente un comportement de revert personnalisé.
Le contrat malveillant doit être invoquable par le protocole cible (par exemple, en tant que gestionnaire de rappel).
2. Créer des données de revert malveillantes
Structurer les données de revert avec un paramètre de longueur falsifié.
3. Exécuter l'ordre via le protocole
Créer un ordre qui déclenchera une interaction avec le contrat malveillant.
Lorsque le protocole traite l'ordre et appelle le contrat malveillant, il revient avec les données créées.
La gestion des erreurs du protocole tente de décoder la raison du revert en utilisant la longueur factice.
4. Déclencher un dépassement de lecture mémoire
Le protocole lit la mémoire en fonction du paramètre de longueur factice.
Cela le fait lire au-delà des limites réelles des données de revert.
Quel est l'impact ?
Refus de service : Les ordres peuvent ne pas s'exécuter correctement, bloquant les opérations légitimes du protocole comme la liquidation de positions défaillantes.
Perturbation de l'exécution des ordres : Le traitement par lots des ordres peut être interrompu, affectant plusieurs utilisateurs.
Gas griefing : Le traitement de données de retour malformées peut consommer une quantité excessive de gas.
La cause profonde :
1. Paramètres de longueur non vérifiés : Le protocole fait confiance à la valeur de longueur fournie dans les données de retour sans validation
2. Vérifications de limites manquantes : Aucune vérification que la longueur revendiquée correspond à la taille réelle des données
L'atténuation :
1. Toujours valider la longueur des données de retour
2. Mettre en œuvre des limites de longueur maximales
Nous sommes fiers d'avoir contribué à sécuriser @GMX_IO grâce à cette découverte.
Quand il faut absolument être sécurisé, Sherlock est le bon choix.
1,94 k
11
Le contenu de cette page est fourni par des tiers. Sauf indication contraire, OKX n’est pas l’auteur du ou des articles cités et ne revendique aucun droit d’auteur sur le contenu. Le contenu est fourni à titre d’information uniquement et ne représente pas les opinions d’OKX. Il ne s’agit pas d’une approbation de quelque nature que ce soit et ne doit pas être considéré comme un conseil en investissement ou une sollicitation d’achat ou de vente d’actifs numériques. Dans la mesure où l’IA générative est utilisée pour fournir des résumés ou d’autres informations, ce contenu généré par IA peut être inexact ou incohérent. Veuillez lire l’article associé pour obtenir davantage de détails et d’informations. OKX n’est pas responsable du contenu hébergé sur des sites tiers. La détention d’actifs numériques, y compris les stablecoins et les NFT, implique un niveau de risque élevé et leur valeur peut considérablement fluctuer. Examinez soigneusement votre situation financière pour déterminer si le trading ou la détention d’actifs numériques vous convient.