Concernant l'incident de sécurité d'IPOR Fusion, le problème clé réside dans le fait que le projet gère ses comptes EOA via EIP-7702, dont la conception du contrat sous-jacent présente une faille — il n'a pas bien limité les appels externes. Résultat, un attaquant a exploité cette vulnérabilité pour créer un contrat de rupture malveillant (Plasma Vault). Ce contrat malveillant peut contourner le mécanisme normal de retrait et transférer directement des fonds depuis le coffre-fort. En résumé, la configuration des permissions du contrat était trop laxiste, ne verrouillant pas complètement quelles opérations pouvaient ou ne pouvaient pas être exécutées. Cet incident nous rappelle encore une fois : même pour des solutions d'extension innovantes (comme EIP-7702), il est essentiel d'être particulièrement prudent lors de leur mise en œuvre, et le contrôle d'accès du contrat de base doit être suffisamment strict.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
13 J'aime
Récompense
13
9
Reposter
Partager
Commentaire
0/400
DevChive
· Il y a 14h
Encore cette histoire de réglage des permissions, c'est la dixième fois... EIP-7702 ne peut même pas résister à la ligne de défense du contrat, elle est complètement inefficace
---
En clair, changer un paramètre peut permettre de voler l'argent de quelqu'un d'autre ? C'est vraiment peu sérieux
---
Et l'audit du contrat ? Toujours la même histoire, des paroles en l'air ?
---
Chaque fois, on dit "la prochaine fois, ça ira", mais c'est toujours la même chose, il faut encore et encore enseigner les bases comme le contrôle d'accès
---
Plasma Vault a l'air risqué, et quand ça tourne mal, combien de personnes se font arnaquer
---
Ils proposent des solutions innovantes, et nous, on découvre des failles innovantes, cette stratégie est vraiment unique
---
Honnêtement, dans ce secteur, il y a tellement de projets qu'ils ont presque écrit "embauchez un hacker pour transférer des fonds" directement dans le code
Voir l'originalRépondre0
ImpermanentSage
· 01-09 09:28
Encore un vieux problème de gestion des permissions, comment se fait-il que des projets soient encore aussi bâclés
Même la technologie la plus avancée ne peut compenser un travail de base mal fait, on ne peut vraiment plus tenir
EIP-7702 lui-même n'a pas de problème, le souci c'est que les utilisateurs ont perdu la tête ?
L'audit des contrats est-il mort ? Ce genre de vulnérabilités basiques passent encore
Et la protection par multi-signature promise ? Elle a été tout simplement ignorée
Les développeurs doivent sérieusement faire une introspection, ne pas encore rejeter la faute sur l'écosystème
Voir l'originalRépondre0
BlockchainNewbie
· 01-07 07:59
Une fois que les permissions sont trop laxistes, les fonds disparaissent. Combien de projets ont déjà trébuché sur ce piège
---
Encore une fois, le contrôle d'accès n'est pas strict... Même la meilleure solution innovante est inutile si le travail de base n'est pas bien fait
---
EIP-7702, une nouveauté aussi récente, et le contrat sous-jacent ose encore être aussi laxiste ? C'est mérité de se faire exploiter
---
La suite Plasma Vault permet de transférer directement de l'argent depuis la base de données, il faut une configuration de permissions tellement défaillante pour permettre à quelqu'un de profiter de la faille
---
Exact, des permissions trop laxistes, c'est comme inviter les hackers, comment certains projets ne tirent-ils pas encore la leçon ?
---
À chaque fois ce genre de problème, l'équipe de développement ne peut vraiment pas payer pour une audit ?
---
Un seul mot : strict. Si ce n'est pas strict, il faut s'attendre à se faire poignarder, pas de compromis
---
L'innovation, c'est bien, mais si on ne peut pas défendre la ligne de défense de base, comment innover ?
---
Le coffre a été vidé directement, cette leçon a un coût trop élevé
---
C'est sûrement parce qu'il n'y a pas eu d'audit ou que l'audit n'est qu'une formalité
Voir l'originalRépondre0
ChainPoet
· 01-07 07:55
Encore une faille de sécurité, l'EIP-7702, c'est ça ? Avant la mise en place de nouvelles choses, il faudrait vraiment faire plusieurs audits.
---
Emm, donc il n'a pas verrouillé le contrôle d'accès, ce qui a permis au contrat de circuit de profiter de cette faiblesse ? Heureusement que cela a été découvert.
---
Une permission trop laxiste permet directement une attaque, la sécurité du contrat n'est vraiment pas une petite affaire.
---
Avant le lancement de solutions innovantes, il y a tellement de pièges, la pression sur les développeurs est vraiment grande. Mais aussi grande soit-elle, il faut assurer une protection de base, non ?
---
Encore une fois, le contrôle d'accès... Quand le secteur prendra-t-il vraiment conscience de cette problématique ?
---
Contourner le mécanisme de retrait pour transférer directement, cette opération est un peu brutale. Rien que d'y penser, ça fait peur.
---
Il semble que l'EIP-7702 lui-même n'ait pas de problème, c'est surtout que les utilisateurs ne l'ont pas bien utilisé.
---
Le contrat de circuit peut sembler impressionnant, mais en réalité, c'est juste que la gestion des permissions n'a pas suivi.
---
Cette affaire prouve encore une fois que plus une chose est nouvelle, plus il faut être prudent. On ne peut pas se contenter d'innover en oubliant la sécurité.
Voir l'originalRépondre0
GweiWatcher
· 01-07 07:55
Encore une fois, la gestion des permissions n'a pas été bien faite, le contrat peut-il vraiment être facilement piraté ?
Voir l'originalRépondre0
HashBandit
· 01-07 07:49
ngl, encore une journée, encore un moment "on a oublié que le contrôle d'accès existe"... à l'époque de mon minage, on savait au moins comment sécuriser nos rigs lol. L'EIP-7702 semblait cool sur le papier, mais c'est exactement pour ça que je ne fais pas confiance aux nouvelles normes sophistiquées avant la troisième année de la blockchain principale... des permissions trop laxistes = les fonds disparaissent, c'est assez simple.
Voir l'originalRépondre0
NFTBlackHole
· 01-07 07:41
Encore une fois, c'est la catastrophe de la gestion des permissions, cette équipe de développeurs devrait vraiment apprendre comment écrire un contrôle d'accès.
EIP-7702 ne pourra pas sauver une architecture de merde, même avec des innovations, si la base n'est pas solide, tout est inutile.
Plasma Vault directement transformé en coffre-fort, c'est risible, c'est ça l'"innovation" ?
Pourquoi retombe-t-on toujours dans les mêmes pièges ? La vérification des contrats est-elle simplement une formalité ?
On sort une nouvelle mécanique et on veut la mettre en ligne immédiatement, c'est une sorte de pari, frère ?
Avec des permissions aussi laxistes, comment ose-t-on mettre le produit en ligne ? Vraiment impressionnant.
Encore une faille de contrat de niveau textbook, quand est-ce qu'ils apprendront enfin la leçon ?
Voir l'originalRépondre0
ArbitrageBot
· 01-07 07:39
Encore une fois, c'est le vieux refrain de la gestion des permissions défaillante. Même l'EIP-7702 ne peut sauver un code de merde.
---
Une conception de contrat à ce niveau, et ils osent le mettre en ligne ? Le contrôle d'accès est une simple façade, c'est mérité qu'on en profite.
---
Dire que ce sont des solutions innovantes, c'est du pipeau. Si la sécurité de base n'est pas assurée, tout est inutile.
---
La manœuvre avec Plasma Vault était vraiment exceptionnelle, ils ont poussé la vulnérabilité à l'extrême. Les ingénieurs devraient vraiment réfléchir.
---
J'en vois trop souvent, c'est toujours la permissivité des permissions qui cause problème.
---
L'EIP-7702 a l'air impressionnant, mais en pratique, ce sont toujours les mêmes vieux problèmes.
---
L'argent est tout simplement disparu, aucune innovation technique ne peut compenser l'absence d'audit.
Voir l'originalRépondre0
MidnightSnapHunter
· 01-07 07:38
La configuration des permissions est vraiment critique, EIP-7702 ne peut pas compenser la mauvaise infrastructure... La leçon tirée de l'IPOR cette fois est sanglante.
Encore une histoire de "nous ne pensions pas qu'on pouvait jouer comme ça", la sécurité des contrats n'a vraiment pas de fin.
Contrat de circuit breaker contournant le mécanisme de retrait ? Cela montre qu'il y a un problème dans l'audit... Sinon, comment personne n'a pensé à cette faille ?
C'est ce qu'on appelle se concentrer uniquement sur l'innovation en oubliant la défense, un contrôle des permissions aussi laxiste est vraiment aberrant.
À chaque fois, c'est la même chose : dès qu'une nouvelle fonctionnalité apparaît, on fonce dessus, et la ligne de défense en sécurité devient aussi fragile que du papier... Quand apprendrons-nous à renforcer d'abord la base avant d'étendre ?
Concernant l'incident de sécurité d'IPOR Fusion, le problème clé réside dans le fait que le projet gère ses comptes EOA via EIP-7702, dont la conception du contrat sous-jacent présente une faille — il n'a pas bien limité les appels externes. Résultat, un attaquant a exploité cette vulnérabilité pour créer un contrat de rupture malveillant (Plasma Vault). Ce contrat malveillant peut contourner le mécanisme normal de retrait et transférer directement des fonds depuis le coffre-fort. En résumé, la configuration des permissions du contrat était trop laxiste, ne verrouillant pas complètement quelles opérations pouvaient ou ne pouvaient pas être exécutées. Cet incident nous rappelle encore une fois : même pour des solutions d'extension innovantes (comme EIP-7702), il est essentiel d'être particulièrement prudent lors de leur mise en œuvre, et le contrôle d'accès du contrat de base doit être suffisamment strict.