Mozilla announced the completion of an independent audit of the client software for connecting to the Mozilla VPN service. The audit included an analysis of a stand-alone client application written using the Qt library and delivered for Linux, macOS, Windows, Android, and iOS. Mozilla VPN is powered by over 400 servers from the Swedish VPN provider Mullvad, located in over 30 countries. Connection to the VPN service is made using the WireGuard protocol.
The audit was performed by Cure53, which at one time audited NTPsec, SecureDrop, Cryptocat, F-Droid and Dovecot projects. The audit covered the verification of source codes and included tests to identify possible vulnerabilities (issues related to cryptography were not considered). The audit identified 16 security issues, 8 of which were recommendations, 5 were rated as low, XNUMX as medium, and XNUMX as high.
At the same time, only one problem with a medium severity level was classified as a vulnerability, since it was the only one that was exploitable. This issue leaked VPN usage information in the captive portal detection code by sending unencrypted direct HTTP requests outside the VPN tunnel and revealing the user's primary IP address in case the attacker could control transit traffic. The problem is solved by disabling the captive portal detection mode in the settings.
The second problem of a medium severity level is related to the lack of proper cleaning of non-numeric values ββin the port number, which allows leaking OAuth authentication parameters by replacing the port number with a string like "[email protected]β, which will cause the tag to be set[email protected]/?code=β¦β alt=ββ> referring to example.com instead of 127.0.0.1.
The third issue, marked as dangerous, allows any local application without authentication to access the VPN client through a WebSocket bound to localhost. As an example, it shows how, with an active VPN client, any site could organize the creation and sending of a screenshot through the generation of the screen_capture event. The problem is not classified as a vulnerability, since WebSocket was used only in internal test builds and the use of this communication channel was only planned in the future to organize interaction with the browser add-on.
Source: opennet.ru