Android Always-On VPN IP leak?

bagel

https://lowlevel.fun/posts/tiny-udp-cannon-android-vpn-bypass/

does anything on graphene happen to mitigate this? i can't think of anything off the top of my head but

anyway this is about a malicious app already on your system, so probably not what most people use always-on vpn to protect against (accidental ip leak)

Johnnyloans

bagel

Turn off private dns to prevent vpn leaks

chinook

Johnnyloans I think you might benefit from reading the linked article. That is not related to the DNS in any way.

bagel I just checked that (compilation of the PoC alone took me faaaaar too long), and the claim here seems to hold -- I didn't see the leak on my up to date phone. It's a bit worrying though that the path is still open, only that the default behaviour has changed.

Also re: "malicious" in your response -- it might as well be a standard behaviour in the apps well known for surveiling users and breaching privacy, like Instagram, TikTok, Yandex, etc. Someone would have to dig through the source code.

userofgos

bagel There are numerous VPN-leaks that are only fixed on GrapheneOS. This is likely pne of those leaks and therefore has no impact on GrapheneOS:

X post: ttps://xcancel.com/GrapheneOS/status/1959305398004924430#m

We have major OS privacy enhancements including Contact Scopes, Storage Scopes, per-app Sensors toggle, per-app Network toggle, per-connection MAC randomization with per-connection DHCP state and much more. We also block all known outbound VPN leaks (5 fixes) and other things.

X post: https://xcancel.com/GrapheneOS/status/2043086870884573462#m

GrapheneOS keeps up with the standard Android privacy patches. We also fix many Android privacy issues ourselves including VPN leaks. We're actively working on fixing remaining VPN issues.

GrapheneOS Website Documentation on improved VPN leak blocking: https://grapheneos.org/features#improved-vpn-leak-blocking

bagel

Johnnyloans sorry, i don't see anything related to dns around the bypass described in the post, could you elaborate? is this a known issue or an unrelated source of leaks?

Johnnyloans

chinook

bagel

I know, their concern is about VPN leaks which GOS has fixed several of them. The only known vpn leak on GOS is via private dns thus:

Johnnyloans Turn off private dns to prevent vpn leaks

Gos comment on vpn leaks: https://github.com/GrapheneOS/os-issue-tracker/issues/5273#issuecomment-3568365234

There's more recent info somewhere saying a GOS dev is only working on VPN issues and I think they've fixed more than 5 vpn issues by now.

chinook

userofgos this part of the features is very vague and doesn't explicitly mention fixing of the abuse of this path.

[NetworkController.cpp] (https://github.com/GrapheneOS/platform_system_netd/blob/16-qpr2/server/NetworkController.cpp) still has both of the fragments of the code allowing system processes to access the network always, regardless.

I can't check the ConnectivityService.java because it's in the restricted repo, maybe the permission check has been added there. Can't find QuicConnectionCloser.java as well

So the default gate value has been changed, part of the code is unchanged and part is maybe changed.

As it stands we're apparently not vulnerable but I am not sure if that's been fixed.

ignoramous

chinook still has both of the fragments of the code allowing system processes to access the network always, regardless.

This isn't unexpected given the way Android's sandboxing model has worked since its inception. "Privileged (vendor or system) apps" have always had a free hand when it came to permission or rule enforcement.

The UID/AID sandbox laid the groundwork and is still the primary enforcement mechanism that separates apps from each other. It has proven to be a solid foundation upon which to add additional sandbox restrictions. However, there are some limitations based on the traditional UNIX UID model: Processes running as root were essentially unsandboxed and possessed extensive power to manipulate the system, apps, and private app data. Likewise, processes running as the system UID were exempt from Android permission checks and permitted to perform many privileged operations.

-"The Android Platform Security Model (2023).

whiskeywalrus

@GrapheneOS Could we get official word on this issue?

whiskeywalrus

Apparently this was fixed in the latest release, as per release notes.