NetGuard doesn't support the standard OS leak blocking like Mullvad and doesn't try to filter DNS so it inherently has leaks. There are no known remote leaks on Android 14 when a VPN app supporting is already active or when it's down. The DNS leaks in this post were partially caused by an app bug that's not fixed and also happen when the VPN is in the process of connecting. The issue with leaks when the VPN is in the process of connecting may be an app bug or an OS bug. It's not clear that it's an OS bug at this point. It was reported to us for GrapheneOS earlier and we've been looking into it.
There's also leak issue which was reported where multicast packets leak outside of the VPN tunnel to the local network. This is highly likely to be an OS bug, unlike the DNS leak issue where it's not yet clear if the OS or the app is the problem. The OS can likely prevent those DNS leaks even if apps don't get fixed but it wasn't necessarily supposed to be responsible for it. From the OS perspective, a VPN app is supposed to set a DNS configuration and not setting that configuration results in partially using the OS DNS.
If you don't mind clarifying, currently GOS uses ASYMMETRIC MTE for the low overhead and to close the soft time constraint in ASYNC MODE. I was having a read though https://googleprojectzero.blogspot.com/2023/08/mte-as-implem...
Where I had come accross possible MTE bypasses in ASYNC mode and I quote:
'Since SIGSEGV is a catchable signal, any signal handlers that can handle SIGSEGV become a critical attack surface for async MTE bypasses'. Moreover, "The concept is simple - if we can corrupt any state that would result in the signal handler concluding that a SIGSEGV coming from a tag-check failure is handled/safe, then we can effectively disable MTE for the process", hence having MTE as ineffective.
Paradoxically, I don't believe this issue is faced regarding SYNC MODE. As you obviously know, 'in asymmetric mode, read memory accesses are processed as SYNC, while write memory accesses are processed as ASYNC'.
does this mean that the signal handlers in write memory are exploitable?
If this be true, does GOS offer a mitigation for this, or can it be possible to simply allow all users to have the option to pick SYNC MTE to bypass this attack surface?
Furthermore, MTE is not enabled for the kernel, would it be possible to have it enabled by choice as well?
Finally, regarding the OS processes to which GOS recently enabled MTE for as an option for its users, does it also include the cellular firmware, IOMMU/SMMU and the software stack that communicates between the isolated chip and the OS? I address this point because, GAL Beniamini stated that:
" That said, up until now we’ve only considered the high-level attack surface exposed to the firmware. In effect, we were thinking of the Wi-Fi SoC and the application processor as two distinct entities which are completely isolated from one another. In reality, we know that nothing can be further from the truth. Not only are the Wi-Fi SoC and the host physically proximate to one another, they also share a physical communication interface". Nonetheless he further states:
"For example, by going over the IOMMU bindings in the Linux Kernel, we can see that apparently both Qualcomm and Samsung have their own proprietary implementations of an SMMU (!), with it’s own unique device-tree bindings. However, suspiciously, it seems that the device tree entries for the Broadcom Wi-Fi chip are missing these IOMMU bindings". Despite that the research is from a couple years, it remains viable evidence that IOMMU although provides adequate protection, it remains an insufficient mechanism on its own and requires further hardening on the software stack. Does GOS address this profound attack vector?
