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.