Dans mon dernier journal de bug bounty, j’ai découvert ce qui ressemblait à un bug d’arrondi critique dans un produit de rendement basé sur des tranches : 100 000 000 000 wei perdus par retrait. Une troncature cumulée sur deux couches de conversion. Un brouillon classé « gravité élevée », prêt à être soumis. Mais ma règle de validation dit : reproduire le problème sur un fork du mainnet avant de croire les chiffres. Le hic :
Le pool mock supposait 18 décimales et un diviseur de 1e30.
Le véritable token a 6 décimales et un diviseur de 1e18.
Cette différence d’échelle de 1e12 faisait que le mock renvoyait zéro à chaque opération de retrait, donc perte == montant demandé. Ce n’était pas un bug du protocole : mon banc de test était cassé. Sur le mainnet, la perte réelle était d’environ 2 à 3 wei par retrait, dans la marge d’arrondi de 100 wei que le développeur avait déjà prévue. C’était voulu. À retenir :
Un constat validé uniquement à l’aide d’un mock est une hypothèse, pas un bug.
uint256 n’a pas d’unité : une erreur d’échelle de 12 ordres de grandeur compile sans problème et passe tous les analyseurs.
Si la « perte » que vous revendiquez est égale au montant total, le problème vient de votre échelle, pas du contrat.
Lisez les commentaires du développeur sur la marge/l’epsilon avant de rédiger votre évaluation de la gravité. Résultat : 0 soumission, 4 candidats écartés lors de la validation, un après-midi honnête, réputation intacte. Avant de signaler votre prochain « arrondi à perte non borné », faites passer une unité dans le vrai contrat sur un fork. Si votre perte tient dans l’epsilon du développeur, vous n’avez pas de constat — vous avez un problème de mock.
#Web3Security #BugBounty #SmartContracts #solidity #CyberSecurity
(Compatible avec un NDA : journal générique, sans nom de protocole, adresse, dépôt ni PoC exploitable.)
Lisez l’analyse technique complète sur mon blog (lien dans le premier commentaire) 👇