Mozilla has announced the completion of an independent audit of the client software for connecting to the Mozilla VPN service. The audit analyzed a standalone client application written using the Qt library and provided for Linux, macOS, Windows, Android, and iOS. Mozilla VPN operates over 400 servers from the Swedish VPN provider Mullvad, located in more than 30 countries. The connection to VPN-the service is made using the WireGuard protocol.
The audit was conducted by Cure53, which had previously audited projects such as NTPsec, SecureDrop, Cryptocat, F-Droid, and Dovecot. The audit involved the review of source code and included tests to identify potential vulnerabilities (cryptographic issues were not considered). The review revealed 16 security issues, with 8 categorized as recommendations, 5 assigned a low severity level, 2 as medium, and 1 as high.
Only one issue with a medium severity level was classified as a vulnerability, as it was the only one exploitable. This issue led to leaking information about VPN usage in the code used to determine a captive portal due to unencrypted direct HTTP requests being sent outside the VPN tunnel, exposing the user's main IP address if an attacker could control the transit traffic. The problem can be resolved by disabling the captive portal detection mode in the settings.
The second medium-level risk issue is related to the lack of proper sanitization of non-numeric values in the port number, allowing for the leakage of OAuth authentication parameters due to substituting the port number with a string like "1234@example.com," which will lead to the installation of a tag <img src="»http://127.0.0.1:1234@example.com/?code=…»" alt="»»">, pointing to example.com instead of 127.0.0.1.
The third issue, marked as dangerous, allows any local application to access the VPN client via WebSocket binding to localhost without authentication. For example, it was shown that with an active VPN client, any site could initiate the creation and sending of a screenshot by generating a screen_capture event. This issue was not classified as a vulnerability since WebSocket was only used in internal test builds, and the use of this communication channel was only planned for future interactions with the browser extension.
Source: opennet.ru
