The original post: /r/mullvadvpn by /u/MullvadNew on 2024-12-11 14:50:09.
Link: https[://]mullvad[.]net/en/blog/the-report-for-the-2024-security-audit-of-the-app-is-now-available
The third party security audit of the Mullvad VPN app has concluded that the app has a high security level. Some non-critical issues were found, and have been fixed to the extent possible.
We have been conducting external security audits of our VPN apps biennially since 2018. We did this in 2018 (https[://]mullvad[.]net/blog/2018/9/24/read-results-security-audit-mullvad-app/), 2020 (https[://]mullvad[.]net/blog/2020/6/25/results-available-audit-mullvad-app/) and 2022 (https[://]mullvad[.]net/en/blog/security-audit-report-for-our-app-available). Two more years have passed and a fourth audit has recently been completed.
Four people from X41 D-Sec performed a penetration test and source code audit of the Mullvad VPN app on all supported platforms for a total of 30 person-days. The audit was performed between 23rd October 2024 and 28th November 2024. The audit report was handed over to Mullvad on 30th November 2024.
Three quotes with key conclusions from the report:
A total of six vulnerabilities were discovered during the test by X41. None were rated as having a critical severity, three as high, two as medium, and one as low. Additionally, three issues without a direct security impact were identified.
Overall, the Mullvad VPN Application appear to have a high security level and are well positioned to protect from the threat model proposed in this report. The use of safe coding and design patterns in combination with regular audits and penetration tests led to a very hardened environment.
In conclusion, the client applications exposed a limited number of relevant vulnerabilities. Mullvad VPN AB addressed them swiftly and the fixes were audited to be working properly.
Read the report
The final report is available on X41's website. We also host all revisions of the report in our git repository.
Overview of findings
A total of six vulnerabilities were discovered during the test by X41. None were rated as having a critical severity, three as high, two as medium, and one as low. Additionally, three issues without a direct security impact were identified.
Mullvad implemented fixes for four of the issues during the audit, and released a new version of the app on the affected platforms around the time when we were handed the audit report.
For more details on each finding, please see our audit documentation in git.
MLLVD-CR-24-01: Signal Handler Alternate Stack Too Small (Severity: High)
The alternative stack configured for the fault signal handler in mullvad-daemon was too small. Since there was no guard page or other stack overrun protections in place, this could lead to the signal handler reading and writing beyond the allocated stack, leading to potential heap corruption and undefined behavior. This affected Android, Linux and macOS.
The fix for this issue is included in version 2024.8 for desktop and version 2024.9 for Android.
We agree with the conclusion from X41 that this vulnerability is not trivial to exploit, but if exploited it would be severe. Due to the low exploitability and the fact that this issue has been present for multiple years without any practical issues surfacing, we decided to not immediately mark existing apps as unsupported, but to release a fixed app version as soon as the audit was complete. We still recommend users on the affected platforms to upgrade to the latest version of the app at their earliest convenience.
MLLVD-CR-24-02: Signal Handler Uses Non-Reentrant Safe Functions (Severity: High)
The fault signal handler in mullvad-daemon called functions which are not signal safe. This could cause undefined behavior, or worst case, be exploitable if the attacker was able to control enough of the program state and externally trigger a fault. This affected Android, Linux and macOS.
The fix for this issue is included in version 2024.8 for desktop and version 2024.9 for Android.
We are not aware of any way to maliciously or accidentally exploit or trigger this bug. This bug has been around for multiple years without any practical issues surfacing. So just like for MLLVD-CR-24-01 above, we decided to not release any quick patch release immediately, but instead wait for the audit to finish and release fixes for all audit findings at the same time.
MLLVD-CR-24-03: Virtual IP Address of Tunnel Device Leaks to Network Adjacent Participant (Severity: Medium)
The Linux kernel (and consequently Android) by default replies to ARP requests for any local target IP address, configured on any interface. This allows an attacker on the same local network to learn the IP address of the VPN tunnel interface by sending an ARP request for every private IPv4 address to the device.
This can be used by an adversary on the same local network to make a qualified guess if the device is using Mullvad VPN. Furthermore, since the in-tunnel IP only changes monthly, the adversary can also possibly identify a device over time.
Linux and Android are the only affected operating systems. For Linux, the fix for this issue is included in version 2024.8.
Android apps, including Mullvad VPN, do not have the permission to change this OS behavior. All Android devices that we know of are affected. We have reported this issue upstream to Google, and recommended that they change the relevant settings to prevent this issue.
We don't consider this a high severity leak since the in-tunnel IP does not disclose a lot about the user. The IP is also automatically rotated every month, only making it a temporary identifier. However, Android users that are worried can log out and back in to the app, as this gives them a new tunnel IP. We are working on solutions that stops the in-tunnel IP from remaining the same over time. When this has been deployed, the issue will be gone on Android also.
MLLVD-CR-24-04: Deanonymization Through NAT (Severity: Medium)
This attack is about how an attacker that can both observe a user’s tunnel traffic and also send UDP traffic with a spoofed sender IP can potentially infer if the user has a connection to a specific internet service. They can do this by sending UDP packets with a unique size with the source address and port set to the internet service they are interested in, the destination IP to the exit VPN relay of the user. They need to do this for every possible destination port. If the user has a connection with that internet service endpoint, eventually one packet will match the NAT table entry on the VPN relay and be forwarded down the tunnel. The attacker can then observe a packet on the tunnel with the unique size (plus VPN headers).
The attack would be hard to carry out. First of all the attacker would need to be able to send UDP packets with spoofed source IPs. Many network providers prevent this, but not all of them. The attacker would also need to be able to observe the client's tunnel traffic. On top of this, the attacker would also need to send large volumes of data with good timing to carry out the attack. If the attacker knows what VPN relay IP address the client exits through, they would need to send tens of thousands of packets before hitting the correct destination port, that match the relay's NAT table entry. Since every Mullvad relay has multiple exit IPs, and each client is assigned a random IP, the attacker would need to figure out what exit IPs the relay has, and repeat the above brute force method on all of them. Moreover, if the client uses multihop, the attacker can't easily infer what exit VPN relay the client uses. The attacker must then perform the above brute force attack against every exit IP of every Mullvad relay. All of this must be carried out in the somewhat short amount of time that the NAT table entry is active on the relay, meaning a time window of just a few minutes around when the client device communicates with the internet service.
This is a privacy problem with how UDP works in general, and not really about Mullvad VPN specifically. Since UDP is becoming a more common and important protocol due to http/3 and similar, Mullvad would love if it became the norm that all network providers performed UDP source address validation, as it would mitigate issues like this to a large extent.
The ...
Content cut off. Read original on https://old.reddit.com/r/mullvadvpn/comments/1hbv4jj/the_report_for_the_2024_security_audit_of_the_app/