Thanks to a generous sponsor, qTox development gets founded for a year! Anthony Bilinski got funded to work full-time for a year and sphaerophoria part-time for a few months. You can read more about this in qTox’s blog post, where Anthony goes into detail on his plans for the year.
DigitalOcean has been providing us with reliable cloud server infrastructure for free since July 2015 — for over 6 years now! They have been very generous with supporting us and a pleasure to work with. Just as an example, in 2018 we asked them for a seemingly outrageous $660 in credits as a budget for that year, which they provided us without any questions asked.
Most of our infrastructure is running on DigitalOcean, including our website, wiki, blog, bootstrap node list, mailing list, some of CI/build system cache, as well as the tox.chat domain — it’s using DigitalOcean as a name server.
DigitalOcean has renewed our sponsorship for 2022, so we will be using their services in 2022 too.
Rest assured, Tox the protocol doesn’t depend on any central servers in order to work, so even if all of our servers were to go down, you would still be able to use Tox.
A stack-based buffer overflow vulnerability was discovered in Toxcore’s networking code that allows a remote attacker to crash the Toxcore process or potentially execute arbitrary code by sending a specially crafted packet. The vulnerability was assigned CVE-2021-44847 identifier.
All users of Toxcore that don’t have UDP disabled are affected. An attacker, knowing the target’s DHT public key, IP and port, can easily craft a packet exploiting the vulnerability. DHT public key, IP and port are all public information, publicly available on the DHT, so an attacker can target any and all Toxcore users by scraping this information from the DHT. This attack can also be used to target DHT bootstrap nodes, thus making new users unable to connect to the DHT network.
The vulnerability was introduced in 71260e38e8d12547b0e55916daf6cadd72f52e19 and fixed in 1b02bad36864fdfc36694e3f96d2dc6c58a891e4. It affects Toxcore versions 0.1.9 – 0.1.11, 0.2.0 – 0.2.12. Toxcore 0.2.13 has the vulnerability patched.
We urge everyone to update to Toxcore 0.2.13 as soon as possible.
If you are unable to update at the moment, you can immediately mitigate the vulnerability by disabling UDP, as this vulnerability happens only on the UDP code path. If you are using a Tox client, look for an option to disable UDP or for a TCP-only mode option. If you are using the library directly, you can disable UDP via the tox_options_set_udp_enabled() API function call.
The buffer being overflown is temp in the handle_request() function, located at DHT.c:365 in Toxcore 0.2.12. The overflow happens on the following line, a few stack frames inside the decrypt_data() function call, due to the 5th argument of decrypt_data() being incorrectly calculated. The 5th argument, length – CRYPTO_SIZE, incorrectly expands to length – 1 + 32 * 2 + 24, when the intention was for it to expand to length – (1 + 32 * 2 + 24). This allows decrypt_data() to write more data into temp buffer than intended, overflowing the buffer and writing past handle_request() function’s stack frame, smashing the stack.
Due to the recent takeover of Freenode IRC and Tox IRC channels being hostilely taken over by the new Freenode staff without any prior notice, we have moved our IRC presence to Libera Chat IRC. All Tox IRC channels have moved to Libera. Any Tox channel you see on Freenode (or any other network) is not official. You can see the up-to-date list of our IRC channels on the wiki.
We are not the only project that has made the switch. Many high-profile projects and communities have left Freenode for Libera: Arch Linux, curl, Django, FFmpeg, Gentoo, Haskell, NGINX, PostgreSQL, Python, Ubuntu, Void Linux, Wikimedia and many more. Some of them have had their channels taken over by the new Freenode staff as well. If you want to learn more about the incident, this blog post has links to many of sources.
Libera Chat is run by the staff that ran Freenode before it got taken over. It’s the continuation of Freenode, with the the same staff, rules, IRC services and many of the same projects. Tox has been on Freenode for almost 8 years, since its very inception in June 2013, and many Tox developers had been using Freenode even before that. It saddens us to have to part with Freenode, even if just in name, and we are grateful to its former staff for managing it for us for such a long time and to Freenode’s sponsors for keeping the lights on. We hope that Libera becomes the new IRC network of choice for open source projects like Freenode once was.
See you on Libera Chat!
This October the Tox developer community will be holding its third annual conference at Metalab in the heart of Vienna, Austria. The event will be 3 full days, from Friday, October 11th to Sunday, October 13th.
We will talk about Tox, and other security related and interesting topics. If you would like to attend, meet the Tox devs, do some live hacking, or just socialize — get a free ticket and reserve a T-shirt. You can find the exact address on your ticket.
Want to give a talk about your project? Please apply here!
If you have any questions about booking, travel arrangements, talks, or anything related to the event, join #toxcon IRC channel on Freenode and contact robinli, strfry or zoff99.
This year’s ToxCon was super fun, thanks to everyone who attended it!
We are planning to hold another ToxCon the next year, so keep an eye for announcements. If you are working on anything fun with Tox and want to share it with the world, consider giving a talk at the next ToxCon — we would be happy to host your talk.
Here are a couple of the photos from the event.
A memory leak bug was discovered in Toxcore that can be triggered remotely to exhaust one’s system memory, resulting in a denial of service attack. The bug is present in the TCP Server module of Toxcore and therefore it affects mostly bootstrap nodes. Regular Tox clients generally have the TCP Server functionality disabled by default, leaving them unaffected.
The bug is fixed in TokTok c-toxcore v0.2.8. The bug is also fixed in the master branch of irungentoo’s toxcore, in commit bf69b54f64003d160d759068f4816b2d9b2e1e21. As a general reminder, if you are still using irungentoo’s toxcore, we strongly encourage you to switch to using TokTok c-toxcore instead as it’s a lot more actively developed and maintained. In fact, irungentoo’s toxcore is neither being developed nor maintained for some time now, aside from merging only the most critical fixes from TokTok c-toxcore from time to time, missing all other important fixes.
If you are using TokTok c-toxcore v0.2.8, you should be unaffected by this bug.
If you are using an older Toxcore, for example a client you use didn’t release an update, make sure that you have the TCP Server functionality disabled in the client settings and you should be unaffected. Some clients, like qTox v1.16.3 and uTox v0.16.1, don’t provide the user with an option to enable the TCP Server, having it always disabled, and other clients, like Toxic v0.8.2, do provide the TCP Server option, but it’s disabled by default. Note that it’s possible that some other clients have the TCP Server option enabled by default.
If you are running a bootstrap node, we strongly encourage you to update to TokTok c-toxcore v0.2.8 rather than disable the TCP Server option. In fact, we will be making Toxcore v0.2.8 the minimal required version for all of the nodes on our bootstrap node list. TCP relay functionality is very useful for mobile users and those behind restrictive NATs, and given that it’s mostly bootstrap nodes that act as TCP relay servers, as clients generally have that option disabled, even a few of those nodes disabling TCP Server functionality would reduce the number of TCP relay servers Tox clients can use considerably.
Update (January 2022): This vulnerability has been assigned CVE-2018-25021 identifier.
As promised, here is more information on ToxCon 2018.
Tox developer community will be holding the conference from Friday, October 12th, to Sunday, October 14th — a 3 day event, at Metalab Vienna, a hackerspace located in the heart of Vienna, Austria. We have many talks prepared for you: from the progress Tox has made in the last 12 months, to security-related and other interesting topics. The the full schedule of the event is available online and there is also an Android app that you can use to get updates if more talks get added.
If you would like to learn more about Tox, meet the developers, do some live hacking, or just socialize, then this is the event for you. The tickets are free and you have an option to buy a sponsored ticket or a ToxCon T-shirt. All money from the sponsored tickets and the T-shirt sales will go towards a dinner for the speakers, and, if there is money left, T-shirts to give away.
For questions about booking, travel arrangements, talks, or anything related to the event feel free to join the #toxcon2018 IRC channel on Freenode and contact one of the event organizers: robinli, sudden6 or zoff99.
In October the Tox developer community will be holding a conference in Vienna. Join us as we talk about the progress we have made during the last 12 months with Tox and other security related topics. There will be lots of talks and other cool things to see.
For more details join the #toxcon2018 IRC channel on Freenode and contact robinli, sudden6 or zoff99.
More information will be revealed in a future post.
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.
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. Thus, being able to learn the IP of an owner of a Tox Id without them accepting a friend request is an undesired behavior.
This is a vulnerability in an implementation of the Tox protocol, a vulnerability in the Toxcore library, not in the Tox protocol itself.
TokTok’s c-toxcore has patched the vulnerability in version 0.2.2.
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. irungentoo’s toxcore was patched after this post was written.
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. The vulnerability was found when Evgeny was working on tox-rs project – a Tox implementation in Rust.
We urge everyone to update to the latest TokTok c-toxcore as soon as possible. You can immediately mitigate the vulnerability for yourself by using TCP-only mode.
Due to the nature of the vulnerability, using Toxcore in which the vulnerability is patched is not enough to protect yourself. The way the patch works is that it can’t protect you from the vulnerability but it can and does protect other peers. So in order to be protected from the vulnerability, everyone should switch to using the patched Toxcore. The more people use the patched Toxcore, the less is the chance to be vulnerable. Note that this applies only to the UDP mode. If you use the TCP-only mode, you are fully protected as you are not affected by the vulnerability.
Details of the vulnerability
Here are the technical details of the vulnerability.
The vulnerability is caused by the Onion module of Toxcore erroneously allowing to onion-route any data, any Tox packets, without a restriction. 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. 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. 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.
One of the packets that are onion-routed is the Announce Request packet. 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. Let’s say Alice announces herself to a bunch of nodes, one of which happened to be Bob. (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. 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. The NAT Ping Request packet is used to ping a node on someone else’s behalf in order to circumvent the NAT. The NAT Ping Request is not meant to be onion routed. 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. Bob doesn’t know Alice’s DHT public key, so Bob will have to make a guess. 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. Eventually Bob’s DHT node will have public key close to Alice’s DHT public key and end up in Alice’s Close Nodes list, making Alice relay the NAT Ping Request packet to it, unknowingly disclosing her IP to Bob. Now Bob knows both Alice’s long term public key and her IP without being friends with her.
What the patch does is make all nodes in the onion path check if the payload of the onion-routed response is a packet kind that shouldn’t be routed through the onion, and if so drop it. It also makes the node closest to the destination of the onion-routed request, which is the only node in the onion path of the onion-routed request that can see which packet kind is sent to the destination node, drop the onion-routed request if it has a packet kind that shouldn’t be routed through the onion. The latter doesn’t matter much as Alice can’t exploit Bob in any way by onion-routing him packets that are not supposed to be onion routed, it’s done more for data sanitization reasons.
Because there are only 3 nodes in the onion path, the source and destination excluded, the patch protects you as long as at least one of the three is using the patched Toxcore.
This vulnerability affects only the UDP mode. In TCP-only mode the Onion module restricts which Tox packets are onion-routed correctly, and the Tox protocol specification is written in such a way that nodes using TCP-only mode can distinguish between onion and non-onion packets. So all of the above applies only to the UDP mode.
Update (January 2022): This vulnerability has been assigned CVE-2018-25022 identifier.