Les développeurs du réseau anonyme Tor ont publié les résultats de leur second audit, mené par la société Radically Open Security d'avril à août 2023 (le premier audit avait été réalisé par la société Cure53 de novembre 2022 à avril 2023). L'examen a porté sur le code permettant le fonctionnement des nœuds de sortie, le navigateur Tor Browser, les composants de l'infrastructure (collecte de métriques, SWBS, API Onionoo) et les outils de test. L'objectif principal de la vérification était d'évaluer les modifications apportées pour améliorer la vitesse et la fiabilité du réseau Tor, telles que le protocole de séparation de trafic Conflux ajouté dans la version Tor 0.4.8 et les méthodes de protection des services Onion contre les attaques par déni de service basées sur la preuve de travail.
Au cours de l'audit, 17 vulnérabilités ont été détectées, dont une seule a été classée comme dangereuse. Quatre vulnérabilités ont été jugées de gravité moyenne, et 12 ont été qualifiées de problèmes de faible gravité. La vulnérabilité la plus critique a été trouvée dans l'application onbasca (Onion Bandwidth Scanner), utilisée pour scanner la bande passante des nœuds du réseau.
La vulnérabilité est causée par la possibilité d'envoyer des requêtes via la méthode HTTP GET, permettant d'effectuer une substitution de requêtes intersites au nom d'un autre utilisateur (CSRF, Cross-Site Request Forgery), offrant ainsi à l'attaquant la possibilité d'ajouter ses propres nœuds de pont dans la base de données par la manipulation du paramètre «bridge_lines». Par exemple, un attaquant peut héberger une page web avec le code JavaScript fetch("http://127.0.0.1:8000/bridge-state/?bridge_lines=obfs4+0.0.0.000000+AAA+cert0+iat-mode0", et si un utilisateur avec une session active du Onion Bandwidth Scanner ouvre cette page, l'IP «0.0.0.0» sera ajoutée à la base de données en son nom.
Problèmes de gravité moyenne :
- Refus de service dans metrics-lib par la transmission d'un grand fichier compressé — puisque le fichier est décompressé en mémoire vive, il est possible d'envoyer une sorte de zip-bombe (par exemple, on peut composer 600 Mo de zéros dans 0,0006 Mo) et provoquer l'épuisement de la mémoire disponible.
- Utilisation dans tor-android-service (utilisé dans le navigateur Tor pour Android) d'un module tiers tun2socks, dont le support a été abandonné.
- Écriture d'un octet nul en dehors du tampon alloué dans le client Tor en raison de l'utilisation de la fonction read_file_to_str_until_eof, qui retourne la taille sans tenir compte du caractère nul.
- Une vulnérabilité dans sbws (Simple Bandwidth Scanner) permettant de rétrograder une connexion HTTPS à HTTP en utilisant une redirection vers HTTP. Un nœud de sortie Tor contrôlé par l'attaquant peut potentiellement exploiter cette vulnérabilité pour faciliter la fuite de jetons API.
Source : opennet.ru
