One Article Review
| Source |  CVE Liste |
|---|---|
| Identifiant | 8351884 |
| Date de publication | 2023-07-03 17:15:09 (vue: 2023-07-03 19:07:06) |
| Titre | CVE-2023-34451 |
| Texte | CometBft est un middleware byzantin pour les défauts (BFT) qui prend une machine de transition d'état et la reproduit sur de nombreuses machines.Le Mempool maintient deux structures de données pour garder une trace des transactions exceptionnelles: une liste et une carte.
Ces deux structures de données sont censées être synchronisées tout le temps dans le sens où la carte suit l'index (le cas échéant) de la transaction dans la liste.Dans `V0.37.0`, et` v0.37.1`, ainsi que dans `V0.34.28`, et toutes les versions précédentes du CometBft Repo2, il est possible de les avoir hors de synchronisation.Lorsque cela se produit, la liste peut contenir plusieurs copies de la même transaction.Étant donné que la carte suit un seul index, il n'est plus possible de supprimer toutes les copies de la transaction de la liste.Cela se produit même si la transaction dupliquée est ensuite engagée dans un bloc.La seule façon de supprimer la transaction est de redémarrer le nœud.
Le problème ci-dessus peut être répété et encore jusqu'à ce qu'un nombre important de transactions soient coincés dans le mempool, afin d'essayer de faire baisser le nœud cible.Le problème est résolu dans les versions `v0.34.29` et` v0.37.2`.Certaines solutions de contournement sont disponibles.L'augmentation de la valeur de `cache_size` dans` config.toml` rend très difficile d'attaquer efficacement un nœud complet.Ne pas exposer la soumission des transactions RPC \\ sait atténuer la probabilité d'une attaque réussie, car l'attaquant devrait alors créer un nœud complet (byzantin) modifié pour pouvoir effectuer l'attaque via P2P.
CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. In `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo2, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node. The above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node. The problem is fixed in releases `v0.34.29` and `v0.37.2`. Some workarounds are available. Increasing the value of `cache_size` in `config.toml` makes it very difficult to effectively attack a full node. Not exposing the transaction submission RPC\'s would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p. |
| Notes | |
| Envoyé | Oui |
| Condensat | 2023 28` 29` 34451 `cache `config `v0 able above all any are attack attacker available because bft block bring byzantine can cometbft committed contain copies create cve data difficult down duplicated effectively even exposing fault fixed from full happens have increasing index keep later list longer machine machines maintains makes many map may mempool middleware mitigate modified node not number only order out outstanding p2p perform possible previous probability problem releases remove repeated replicates repo2 restarting rpc same sense several single sizable size` some state structures stuck submission successful supposed sync takes target them then these time tolerant toml` track tracks transaction transactions transactions: transition try two until value very way well when workarounds would |
| Tags | |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.