If Bob makes a bad guess and Alice doesn’t relay the packet to his node, Bob can re-try by sending the NAT Ping Request packet to Alice for a new DHT node, repeating this process as many times as he wants. Bob doesn’t know Alice’s DHT public key, so Bob will have to make a guess. Alice will receive the NAT Ping Request packet and will diligently relay it to the Bob’s DHT node if it happened to be in Alice’s Close List of nodes, which will happen only if the DHT public key of Bob’s node is close to the DHT public key of Alice’s node. The NAT Ping Request is not meant to be onion routed. The NAT Ping Request packet is used to ping a node on someone else’s behalf in order to circumvent the NAT. If Bob is malicious, he could spawn many new DHT nodes, and send back to Alice a NAT Ping Request packet for one of its newly created nodes.
(If Bob is malicious, he can purposefully keep re-generating his DHT keypair until his public key becomes close to Alice’s long term public key as to guarantee Alice announcing to him.) Based on the Announce Request packet, Bob now knows Alice’s long term public key and has a way to contact her back though the established onion path. Let’s say Alice announces herself to a bunch of nodes, one of which happened to be Bob. It’s used to announce ourselves to nodes close to our long term public key, the one that is a part of Tox Id, and the payload of that packet includes the long term public key itself. One of the packets that are onion-routed is the Announce Request packet. The way the onion routing is defined in the Tox specification and Toxcore erroneously not restricting the packets that can be onion-routed allows for some interesting interactions that weren’t meant to happen. Alice has no way to distinguish onion and non-onion packets - she has no idea if the packet originated from the node it received the packet from, or if the packet was relayed on someone else’s behalf as part of an onion-routing. By the Tox protocol specification, when Alice makes an onion-routed request to Bob and then Bob sends an onion-routed response back to Alice, the payload of the onion-routed response sent by Bob arrives to Alice as it is, stripped of any identification that it was ever onion-routed by the last onion hop, and is interpreted as a regular Tox packet by Alice. The vulnerability is caused by the Onion module of Toxcore erroneously allowing to onion-route any data, any Tox packets, without a restriction. Here are the technical details of the vulnerability. If you use the TCP-only mode, you are fully protected as you are not affected by the vulnerability. Note that this applies only to the UDP mode. The more people use the patched Toxcore, the less is the chance to be vulnerable. So in order to be protected from the vulnerability, everyone should switch to using the patched Toxcore.
#Toxcore qtox Patch
The way the patch works is that it can’t protect you from the vulnerability but it can and does protect other peers. You can immediately mitigate the vulnerability for yourself by using TCP-only mode.ĭue to the nature of the vulnerability, using Toxcore in which the vulnerability is patched is not enough to protect yourself.
#Toxcore qtox update
We urge everyone to update to the latest TokTok c-toxcore as soon as possible. The vulnerability was found when Evgeny was working on tox-rs project – a Tox implementation in Rust. The vulnerability was privately reported to us by Evgeny Kurnevsky on April 14th and publicly disclosed with our permission on April 15th, along with a patch fixing the vulnerability, made by Evgeny Kurnevsky. irungentoo’s toxcore was patched after this post was written.
irungentoo’s toxcore doesn’t have the vulnerability patched as of this moment and it’s unknown if it ever will, as it hasn’t been actively maintained for years. TokTok’s c-toxcore has patched the vulnerability in version 0.2.2. TCP-only mode is not affected by the vulnerability. The vulnerability affects only UDP mode of operation. The vulnerability affects both TokTok’s c-toxcore and irungentoo’s toxcore. This is a vulnerability in an implementation of the Tox protocol, a vulnerability in the Toxcore library, not in the Tox protocol itself. Thus, being able to learn the IP of an owner of a Tox Id without them accepting a friend request is an undesired behavior. The Tox protocol is designed in such a way that only friends (contacts) which you have accepted friend requests of are able to learn your IP based on your Tox Id and no one else. A vulnerability was discovered in Toxcore that allows one to learn the IP of a target user by only knowing their Tox Id and without being friends with the target user.
0 kommentar(er)
