> FortiClient VPN and SmartVPN have 4,134,648 cumulative Google Play installs between them, while Google reports more than 3 billion active Android devices.
A very strange way to reason about killing an API instead of fixing the VPN issue (as someone from Google already suggested they're planning on doing). "Only 4 million people use this, we should kill it" is exactly the kind of reasoning Microsoft in the 2000s would use to kill the ability to install Linux on a PC.
brinepot
'Closed without action' is the tell. A leak that Google knows about and leaves in place isn't a bug anymore, it's a feature they're comfortable with.
show comments
ValdikSS
Android has a way to bind the socket to the interface: Network.bindSocket, this is a setsockopt(SO_BINDTODEVICE) wrapper with access control.
The access to it is controlled by the VPN application. Some applications could be allowed to connect directly when the VPN is active and routing all the traffic by default, some could use VPN if configured not to use it by default.
However starting with Linux kernel 5.7, the unprivileged userspace can now call setsockopt(SO_BINDTODEVICE) directly and use VPN or non-VPN interface even if restricted by the VPN client.
Not fixed in any Android (incl. Graphene, which has fixes for other leaks, but not this) to the day.
PoC is as simple as "curl --interface [ifname, not IP] ifconfig.co" in termux.
The stupid thing about Android is that it requires you to set a PIN to use Always-on VPN which is necessary for traffic filtering (as Android doesn't provide access to nft).
show comments
exceptione
> A proper fix would require changes in the Android system. The researcher who discovered the leak has reported the issue to the Android Vulnerability Reward Program, but according to the researcher the issue was closed without action. This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
If the account given by the researcher is correct, we cannot rule out that Google deliberately introduced or wanted to keep the leak in place.
show comments
nonamesleft
As a quick kludge use an USB-C wlan network adapter that lacks the functionality for this type of connection (albeit that won't help you with a cellular connection)?
show comments
aucisson_masque
> This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
Good guy Google, as usual.
show comments
dingdong2026
Just another data point proving what we already know:
Google is Evil.
You might as well use Meta or Microsoft products. Or Phillip Morris. Blame yourself for the fallout.
potatoproduct
Surprised this hasn't blown up more!
TutleCpt
Mullvad did a really good job writing up this blog post. And yet again GrapheneOS to the rescue.
gib444
I guess the best advice remains to only use wifi to connect to a router which forces traffic over a VPN and never use mobile data?
Do any similar leaks exists on iOS currently?
gib444
GrapheneOS is affected too. They've been aware since at least 29th July and are working on a fix, no ETA.
GOS say security issues are high priority.
There is no update the GitHub issue for 2 weeks except for deleting a comment by the reporter yesterday.
GOS developers have been busy working on a Messages rewrite and that got released in alpha yesterday.
show comments
tosti
You're definately not hiding something if all your traffic goes out to a single IP address and a single pair of source and destination ports.
> FortiClient VPN and SmartVPN have 4,134,648 cumulative Google Play installs between them, while Google reports more than 3 billion active Android devices.
A very strange way to reason about killing an API instead of fixing the VPN issue (as someone from Google already suggested they're planning on doing). "Only 4 million people use this, we should kill it" is exactly the kind of reasoning Microsoft in the 2000s would use to kill the ability to install Linux on a PC.
'Closed without action' is the tell. A leak that Google knows about and leaves in place isn't a bug anymore, it's a feature they're comfortable with.
Android has a way to bind the socket to the interface: Network.bindSocket, this is a setsockopt(SO_BINDTODEVICE) wrapper with access control.
The access to it is controlled by the VPN application. Some applications could be allowed to connect directly when the VPN is active and routing all the traffic by default, some could use VPN if configured not to use it by default.
However starting with Linux kernel 5.7, the unprivileged userspace can now call setsockopt(SO_BINDTODEVICE) directly and use VPN or non-VPN interface even if restricted by the VPN client.
Not fixed in any Android (incl. Graphene, which has fixes for other leaks, but not this) to the day.
PoC is as simple as "curl --interface [ifname, not IP] ifconfig.co" in termux.
This paper goes into much more detail: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
The stupid thing about Android is that it requires you to set a PIN to use Always-on VPN which is necessary for traffic filtering (as Android doesn't provide access to nft).
As a quick kludge use an USB-C wlan network adapter that lacks the functionality for this type of connection (albeit that won't help you with a cellular connection)?
> This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
Good guy Google, as usual.
Just another data point proving what we already know:
Google is Evil.
You might as well use Meta or Microsoft products. Or Phillip Morris. Blame yourself for the fallout.
Surprised this hasn't blown up more!
Mullvad did a really good job writing up this blog post. And yet again GrapheneOS to the rescue.
I guess the best advice remains to only use wifi to connect to a router which forces traffic over a VPN and never use mobile data?
Do any similar leaks exists on iOS currently?
GrapheneOS is affected too. They've been aware since at least 29th July and are working on a fix, no ETA.
GOS say security issues are high priority.
There is no update the GitHub issue for 2 weeks except for deleting a comment by the reporter yesterday.
GOS developers have been busy working on a Messages rewrite and that got released in alpha yesterday.
You're definately not hiding something if all your traffic goes out to a single IP address and a single pair of source and destination ports.