Developers of the anonymous Tor network have published the results of an audit of the Tor Browser and the OONI Probe, rdsys, BridgeDB, and Conjure tools developed by the project, which are used for anonymous network connections that are protected from eavesdropping and traffic analysis mechanisms. The audit was conducted by Cure53 from November 2022 to April 2023.
During the audit, 9 vulnerabilities were identified, two of which were classified as dangerous, one was assigned an average level of danger, and 6 were assigned to problems with a minor level of danger. Also, 10 issues were found in the code base that were classified as non-security flaws. In general, the code of the Tor project is marked as corresponding to the practices of secure programming.
The first dangerous vulnerability was present in the backend of the distributed rdsys system, which provides resources such as proxy lists and download links to censored users. The vulnerability was caused by a lack of authentication when accessing the resource registration handler and allowed the attacker to register their own malicious resource for delivery to users. Operation is reduced to sending an HTTP request to the rdsys handler.
The second dangerous vulnerability was found in Tor Browser and was caused by the lack of digital signature verification when receiving a list of bridge nodes via rdsys and BridgeDB. Since the list is loaded into the browser at the stage before connecting to the anonymous Tor network, the lack of verification by cryptographic digital signature allowed the attacker to substitute the contents of the list, for example, by intercepting the connection or hacking the server through which the list is distributed. In the event of a successful attack, an attacker could arrange for users to connect via their own compromised bridge node.
A medium-risk vulnerability was present in the rdsys subsystem in the build deployment script and allowed an attacker to raise their privileges from the nobody user to the rdsys user, if they had access to the server and could write to a directory with temporary files. Exploiting the vulnerability is limited to replacing the executable file placed in the /tmp directory. Obtaining rdsys user rights allows an attacker to make changes to executable files launched via rdsys.
Low-risk vulnerabilities were mainly associated with the use of outdated dependencies that contained known vulnerabilities, or with the possibility of committing a denial of service. Minor vulnerabilities in Tor Browser include the ability to bypass the JavaScript execution ban when setting the highest level of protection, the lack of restrictions on downloading files, and a potential information leak through the user's home page, which allows you to track users between restarts.
Currently, all vulnerabilities have been fixed, among other things, authentication for all rdsys handlers has been implemented and verification of lists uploaded to Tor Browser by digital signature has been added.
Additionally, you can note the release of Tor Browser 13.0.1. The release is synchronized with the Firefox 115.4.0 ESR codebase, which fixes 19 vulnerabilities (13 are considered dangerous). The Tor Browser version 13.0.1 for Android has been updated with vulnerability fixes from the Firefox 119 branch.
----
The developers of the anonymous Tor network published the results of the second audit, which was conducted by Radically Open Security from April to August 2023 (before that, from November 2022 to April 2023, Cure53 conducted the first audit). The review affected the code for ensuring the operation of exit nodes, the Tor Browser, infrastructure components (collecting metrics, SWBS, Onionoo API), and testing utilities. The main task of the re-check was to evaluate changes made to improve the speed and reliability of the Tor network, such as the Conflux traffic sharing protocol added in Tor 0.4.8 and methods for protecting Onion services from DoS attacks based on proof of work.
The audit revealed 17 vulnerabilities, only one of which is classified as dangerous. Four vulnerabilities are assigned an average level of danger, and 12 are classified as problems with a minor level of danger. The most dangerous vulnerability was identified in the onbasca (Onion Bandwidth Scanner) application, which is used to scan the bandwidth of network nodes.
The vulnerability is caused by the ability to send requests via the HTTP GET method, which allows you to perform cross-Site request forgery on behalf of another user (CSRF, Cross-Site Request Forgery), which allows an attacker to add their bridge nodes to the database by manipulating the "bridge_lines"parameter. For example, an attacker can place a web page with the JavaScript code fetch ("http://127.0.0.1:8000/bridge-state/? bridge_lines=obfs4+0.0.0.0%3A00000+AAA+cert%3D0+iat-mode%3D0", and if this page is opened by a user with an active session to Onion Bandwidth Scanner, the IP "0.0.0.0"will be added to the database on their behalf.
Problems with the average level of danger:
* Denial of service in metrics-lib by transferring a large compressed file - since the file is decompressed into RAM, you can transfer a kind of zip bomb (for example, you can pack 600 MB of zeros into 0.0006 MB) and cause the available memory to run out.
* Using the third-party tun2socks module in the tor-android-service (used in Tor browser for Android), which is no longer supported.
* Writing a zero byte outside the allocated buffer boundary in the Tor client due to the use of the read_file_to_str_until_eof function, which returns the size without taking into account the zero character.
* A vulnerability in sbws (Simple Bandwidth Scanner) that allows you to roll back an HTTPS connection to HTTP using a redirect to HTTP. The Tor exit node controlled by the attacker can potentially use this vulnerability to leak API tokens.
During the audit, 9 vulnerabilities were identified, two of which were classified as dangerous, one was assigned an average level of danger, and 6 were assigned to problems with a minor level of danger. Also, 10 issues were found in the code base that were classified as non-security flaws. In general, the code of the Tor project is marked as corresponding to the practices of secure programming.
The first dangerous vulnerability was present in the backend of the distributed rdsys system, which provides resources such as proxy lists and download links to censored users. The vulnerability was caused by a lack of authentication when accessing the resource registration handler and allowed the attacker to register their own malicious resource for delivery to users. Operation is reduced to sending an HTTP request to the rdsys handler.
The second dangerous vulnerability was found in Tor Browser and was caused by the lack of digital signature verification when receiving a list of bridge nodes via rdsys and BridgeDB. Since the list is loaded into the browser at the stage before connecting to the anonymous Tor network, the lack of verification by cryptographic digital signature allowed the attacker to substitute the contents of the list, for example, by intercepting the connection or hacking the server through which the list is distributed. In the event of a successful attack, an attacker could arrange for users to connect via their own compromised bridge node.
A medium-risk vulnerability was present in the rdsys subsystem in the build deployment script and allowed an attacker to raise their privileges from the nobody user to the rdsys user, if they had access to the server and could write to a directory with temporary files. Exploiting the vulnerability is limited to replacing the executable file placed in the /tmp directory. Obtaining rdsys user rights allows an attacker to make changes to executable files launched via rdsys.
Low-risk vulnerabilities were mainly associated with the use of outdated dependencies that contained known vulnerabilities, or with the possibility of committing a denial of service. Minor vulnerabilities in Tor Browser include the ability to bypass the JavaScript execution ban when setting the highest level of protection, the lack of restrictions on downloading files, and a potential information leak through the user's home page, which allows you to track users between restarts.
Currently, all vulnerabilities have been fixed, among other things, authentication for all rdsys handlers has been implemented and verification of lists uploaded to Tor Browser by digital signature has been added.
Additionally, you can note the release of Tor Browser 13.0.1. The release is synchronized with the Firefox 115.4.0 ESR codebase, which fixes 19 vulnerabilities (13 are considered dangerous). The Tor Browser version 13.0.1 for Android has been updated with vulnerability fixes from the Firefox 119 branch.
----
The developers of the anonymous Tor network published the results of the second audit, which was conducted by Radically Open Security from April to August 2023 (before that, from November 2022 to April 2023, Cure53 conducted the first audit). The review affected the code for ensuring the operation of exit nodes, the Tor Browser, infrastructure components (collecting metrics, SWBS, Onionoo API), and testing utilities. The main task of the re-check was to evaluate changes made to improve the speed and reliability of the Tor network, such as the Conflux traffic sharing protocol added in Tor 0.4.8 and methods for protecting Onion services from DoS attacks based on proof of work.
The audit revealed 17 vulnerabilities, only one of which is classified as dangerous. Four vulnerabilities are assigned an average level of danger, and 12 are classified as problems with a minor level of danger. The most dangerous vulnerability was identified in the onbasca (Onion Bandwidth Scanner) application, which is used to scan the bandwidth of network nodes.
The vulnerability is caused by the ability to send requests via the HTTP GET method, which allows you to perform cross-Site request forgery on behalf of another user (CSRF, Cross-Site Request Forgery), which allows an attacker to add their bridge nodes to the database by manipulating the "bridge_lines"parameter. For example, an attacker can place a web page with the JavaScript code fetch ("http://127.0.0.1:8000/bridge-state/? bridge_lines=obfs4+0.0.0.0%3A00000+AAA+cert%3D0+iat-mode%3D0", and if this page is opened by a user with an active session to Onion Bandwidth Scanner, the IP "0.0.0.0"will be added to the database on their behalf.
Problems with the average level of danger:
* Denial of service in metrics-lib by transferring a large compressed file - since the file is decompressed into RAM, you can transfer a kind of zip bomb (for example, you can pack 600 MB of zeros into 0.0006 MB) and cause the available memory to run out.
* Using the third-party tun2socks module in the tor-android-service (used in Tor browser for Android), which is no longer supported.
* Writing a zero byte outside the allocated buffer boundary in the Tor client due to the use of the read_file_to_str_until_eof function, which returns the size without taking into account the zero character.
* A vulnerability in sbws (Simple Bandwidth Scanner) that allows you to roll back an HTTPS connection to HTTP using a redirect to HTTP. The Tor exit node controlled by the attacker can potentially use this vulnerability to leak API tokens.
