2 ms·

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

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.

ysnp 13d ago
Can you report this to GrapheneOS?
- ValdikSS 13d ago
  It has been reported to Google (as a security bug) and to GrapheneOS as a comment in one of the very similar VPN leak issue on github. GrapheneOS has deleted my comment, probably because they assumed it was AI-generated or something, I've copied the report I sent to Google there.
  - deleted 11d ago
    [deleted]
  - deleted 11d ago
    [deleted]
  - grapheneos 11d ago
    It was believed to be an AI generated comment and the issue is already known. We solved it as part of VPN lockdown mode which means it isn't solved for profiles not using a VPN in lockdown mode yet. We could expand our already working approach to always be active but we were concerned about compatibility so we scoped it to VPN lockdown mode.
exceptione 12d ago
Imho, the interface should not even be in the namespace to begin with. Unshare netns, then using pasta allows you to pass a user-space network adapter inside. https://passt.top/passt/about/ https://passt.top/passt/about/ Caveat: I am no expert on Android.
grapheneos 11d ago
GrapheneOS does block SO_BINDTODEVICE when VPN lockdown mode is enabled. It doesn't yet block apps in profiles not using a VPN in lockdown mode from using a VPN in another profile due to compatibility concerns but we can likely block it.

ysnp 13d ago

Can you report this to GrapheneOS?

ValdikSS 13d ago
It has been reported to Google (as a security bug) and to GrapheneOS as a comment in one of the very similar VPN leak issue on github. GrapheneOS has deleted my comment, probably because they assumed it was AI-generated or something, I've copied the report I sent to Google there.
- deleted 11d ago
  [deleted]
- deleted 11d ago
  [deleted]
- grapheneos 11d ago
  It was believed to be an AI generated comment and the issue is already known. We solved it as part of VPN lockdown mode which means it isn't solved for profiles not using a VPN in lockdown mode yet. We could expand our already working approach to always be active but we were concerned about compatibility so we scoped it to VPN lockdown mode.

exceptione 12d ago

Imho, the interface should not even be in the namespace to begin with. Unshare netns, then using pasta allows you to pass a user-space network adapter inside. https://passt.top/passt/about/ https://passt.top/passt/about/ Caveat: I am no expert on Android.

grapheneos 11d ago

GrapheneOS does block SO_BINDTODEVICE when VPN lockdown mode is enabled. It doesn't yet block apps in profiles not using a VPN in lockdown mode from using a VPN in another profile due to compatibility concerns but we can likely block it.