Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • > 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.

    by aucisson_masque
  • 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).
    by codedokode
  • Original post by the author: https://news.ycombinator.com/item?id=49096839
    by bordercontrol

  •   > 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.
    by exceptione
  • This paper goes into much more detail: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
    by exceptione
  • > 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.

    by jeroenhd
  • '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.
    by brinepot
  • 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.

    by ValdikSS

Explore Birbla archives

Another way to leak traffic on Android has been discovered · Birbla