Bug de transfert Super Sushi Samurai

Le 21 mars 2024, le jeton GameFi de Blast Super Sushi Samurai (SSS) a perdu environ 4,8 millions de dollars à cause d'un bug de logique de transfert de jetons : transférer des jetons à soi-même créditait le solde sans le débiter, doublant les avoirs de l'expéditeur à chaque self-transfer. Un attaquant a bouclé les self-transfers pour minter un solde effectivement infini, puis a dumpé dans le pool de liquidité. Un white-hat avait indépendamment découvert le même bug et tentait de sauver les fonds quand l'acteur malveillant a frappé.

Ce qui s'est passé

L'implémentation transfer ERC-20 de SSS gérait le cas from == to incorrectement — elle ajoutait le montant au destinataire avant de soustraire de l'expéditeur, donc un self-transfer augmentait nettement le solde. Des self-transfers répétés ont gonflé le SSS de l'attaquant à une taille arbitraire ; vendre cette offre a drainé le pool SSS/WETH de ~4,8 M$.

Conséquences

• Un white-hat a récupéré une partie (il courait pour sécuriser les fonds via le même bug).
• Le projet a négocié des retours partiels ; SSS s'est effondré.

Pourquoi c'est important

Super Sushi Samurai est le même bug comptable self-transfer / from == to que MonoX (échanger un jeton contre lui-même) — la classe d'entrées dégénérées. Aucun utilisateur légitime ne fait de self-transfer pour doubler son solde ; précisément parce que c'est dégénéré, ce n'est pas testé. La règle récurrente du catalogue : testez les entrées qu'aucun utilisateur honnête ne soumettrait jamais, parce que ce sont exactement les entrées qu'un attaquant soumettra. Le property-based testing (« pour tout a,b : l'invariant balanceOf tient après transfer(a,b) y compris a==b ») attrape ça trivialement ; les tests par exemple écrits autour du comportement utilisateur attendu, jamais.