I2P Netzwerk seit Anfang Mai wieder unter Dauerbeschuss

Kommentare
1

ddos, Pfeile
ddos, Pfeile2560Ă—1551 534 KB

Kommentare zu folgendem Beitrag: I2P Netzwerk seit Anfang Mai wieder unter Dauerbeschuss

2

Der Angriff wird mit der neusten I2P Version 2.3.0 nicht mehr möglich sein.
Da diese neue I2P Version einen Fehler fixt, der den Angriff überhaupt erst ermöglicht hat.

This release contains fixes for CVE-2023-36325. CVE-2023-36325 is a context-confusion bug which occurred in the bloom filter. An attacker crafts an I2NP message containing a unique messageID, and sends that messageID to a client. The message, after passing through the bloom filter, is not allowed to be re-used in a second message. The attacker then sends the same message directly to the router. The router passes the message to the bloom filter, and is dropped. This leaks the information that the messageID has been seen before, giving the attacker a strong reason to believe that the router is hosting the client. This has been fixed by separting the bloom filter’s functionality into different contexts based on whether a message came down a client tunnel, an exploratory tunnel, was sent to the router directly. Under normal circumstances, this attack takes several days to perform successfully and may be confounded by several factors such as routers restarting during the attack phase and sensitivity to false-positives. Users of Java I2P are recommended to update immediately to avoid the attack.

Im Zuge der Behebung dieses Kontexts-Verwirrungsfehlers wurden einige Strategien überarbeitet, um defensiv zu kodieren, gegen diese Art von Lecks. Dazu gehören Optimierungen am netDb, die zinsbegrenzenden Mechanismen und das Verhalten von Flutfill-Routern.

DETAILS: I2P 2.3.0

Changes

  • netDb: Throttle bursts of netDB lookups
  • Sybil/Blocklist: Allow users to override blocklist expiration with an interval
  • DTG: Provide an API for extending DTG with a plugin
  • Addressbook: add notbob’s main addressbook to the default subscriptions.
  • Console: Add Ramble and notbob to console homepage

Bug Fixes

  • Fix replay attack: CVE-2023-36325
  • Implement handling of multihomed routers in the netDb
  • Fully copy new leaseSets when a leaseSet recievedAsPublished overwrites a leaseSet recievedAsReply
1 Like
3

Ist das ĂĽberhaupt sinnvoll, dass der Router die empfange ID erstmal an den Filter weiterleiten muss, bevor das System dann bemerken kann, dass die ID zweimal genutzt wurde?!
Müsste nicht, meines Erachtens, der Analyst (also der Bloom-Filter) VOR dem Router sitzen und quasi wie eine Firewall, die doppelte ID erst gar nicht mehr an den Router ranlassen…?
Vllt habsch da ja etwas misbegrepen… :wink: