German cybersecurity firm Cure53 has conducted a wide-scoped security audit on the Tor Browser, and its few non-critical findings confirm the project’s excellent security posture.
The Tor Browser, a private and secure browser created by the Tor Project, is a free and open-source web browser designed specifically for accessing The Onion Router (Tor) network. The Tor network is a volunteer-operated network of thousands of relays worldwide, which bounce and redirect user traffic to preserve user privacy and anonymity.
The software enables users to circumvent internet blocks, evade state and ISP-level tracking, access anonymous hidden services, dodge fingerprinting, automatically reject all cookies, and many more. Hence, its security is crucial, as if hackers or state actors could breach Tor’s security model, its core values would be compromised, along with the trust of its users.
To bolster user trust and fix any issues that have slipped from its own team of developers and contributing volunteers, Tor ordered Cure53 to carry out an extensive, 72-days-long audit on the software, examining the UI elements, Rdsys (resource distribution system), BridgeDB, Conjure implementation, and its infrastructure. Cuer53 is a well-known auditing firm in Germany that has also audited NordVPN and ExpressVPN.
Few problems found
Cure53 identified two high-severity flaws and one moderate issue. All three vulnerabilities have been addressed, and users received fixes through security updates following the audit’s conclusion in April 2023. The three flaws are:
- Bridge list lacks signature (high) – The non-cryptographically signed list of bridges Tor obtains via API from Rdsys/BridgeDB can be tampered with during transit before connectivity to the Tor network is established, leading the user to unintended and potentially censor-controlled bridge instances. For such an attack to work, the adversary needs to be able to eavesdrop on the user’s connection.
- Lack of resource registration authentication (high) – Rdsys lacks authentication for the resource registration endpoint, allowing an attacker to register arbitrary malicious resources that will be distributed to users.
- Privilege escalation from ‘nobody’ to ‘rdsys’ in deploy script (medium) – A local privilege escalation flaw in a deploy script allowing an attacker who has already established access on the user’s system to elevate themselves to the privileges of the rdsys daemon user. The issue is exploitable only within a narrow time frame of a few seconds.
All in all, the above issues are not critical to the security of Tor, and their exploitation carries practical complexity. Cure53 identified another six low-severity vulnerabilities and ten informational issues. None of those constitutes a dire threat to users.
“The auditors remarked that although the scope was large, the number of issues uncovered was low and that Tor, in general, adopts an admirably robust and hardened security posture and sound design decisions,” reads Tor Project’s announcement of the results.
“The auditor further said our code was written to a “first-rate standard and conformed to secure coding practices” and that we have adopted highly-advanced and deliberately security-focused building processes around Tor Browser because of our reproducible builds, build signing, and more.”
While they constitute excellent proactive security practices, audits cannot be taken as guarantees for security. There can always be critical-severity flaws that auditors miss, and this has been highlighted many times in the recent past with hackers compromising recently audited projects leveraging an unknown vulnerability.
The Tor Project states it will continue conducting these regular security assessments to uncover and fix potential problems before malicious actors can find and exploit them.
Anonymous
This was surprising to me . This was a big job Cure 53 did . I had stopped using Tor for a while because I didnt think it was secure anymore .
Will Wheaton
Just One thing, who look after the nodes. Nsa? And slow speed is the main problem.