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.
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.
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/
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.
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.
Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.
I am not sure why all your comments are flagged, but here is my response to your other comment:
> We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.
Thanks, great to hear. Given the slew of bugs you uncovered it seems the Android implementation has some rough edges. Would `pasta` be helpful to you? It allows you to unshare netns and then pass a user-space network adapter inside. https://passt.top/passt/about/ Podman leverages this one as well in more recent versions.
The past couple weeks of our replies were maliciously flagged. We've made a post about it on social media as we've had to do before when this happens. This happens very regularly to posts by GrapheneOS or posts which simply support GrapheneOS. There are a bunch of malicious accounts which show up to each thread about GrapheneOS to make personal attacks towards our team, baselessly claim it's a honey pot, promote non-hardened products reducing privacy/security compared to AOSP and to make a bunch of disingenuous attacks towards it. The attacks towards our team often involve fabricated stories about us and harassment content. There's an account active in many of these recent threads making disingenuous replies and spreading Kiwi Farms harassment content in their profile:
This comment specifically was also auto-collapsed for me, without being marked as flagged or dead.
It might help to ask moderation about this. Could be an artefact of brigarding or something similar.
I also wouldn't worry about individual accounts so much. Asking for others to be banned, linking mirrored profiles, etc. That is just not the stuff many users like to read on HN. I think your technical content is truly amazing on its own already.
The past several weeks of our replies were wrongly flagged. None of our posts were in any way inappropriate and it's entirely appropriate to ask for help getting it undone. On the other hand, you're repeatedly making personal attacks on our team, engaging in doxxing and spreading harassment content. You're directly pointing people to Kiwi Farms harassment content with blatant libel and doxxing. There have been years of this harassment on Hacker News without it being addressed by the moderators. We're not going to be tolerating it anymore. Hacker News actively engages in moderation and therefore has no excuse to be permitting this harassment and leaving up years of it across many threads.
We've previously emailed them with no result. This time around we got a reply about this specific account targeting us but it isn't resolved. We don't have much optimism about getting the many past threads with personal attacks based around fabricated stories and harassment content addressed without doing more than asking via email.
> 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.
Original researcher here. Android could retain its complete platform-managed IKEv2/IPsec VPN implementation for Settings, carriers, and other privileged system components, while requiring third-party VPN applications to use `VpnService` and their own userspace implementation. VPN functionality would remain on both sides.
What would disappear is the narrow hybrid feature that lets an ordinary app configure kernel transport-mode IPsec on individual sockets, along with some performance and provisioning conveniences.
The problem is that Android's IPsec machinery is highly privileged and used by carriers to configure various parts of the telephony stack. Giving third-party apps access to this machinery is extremely bad system architecture.
So, what I am saying is to keep the platform-managed implementation of IKEv2/IPsec VPN and let third-party apps use their own implementations through `VpnService`, as they already do. The two apps you cited, in fact, support both. Most apps support only userspace.
Considering that most apps support only userspace, I think it is safe to assume that most users of these two apps also use only their normal userspace implementation, not the hybrid user-platform implementation.
So, it is not about killing VPN functionality or anything like that, but about imposing a strict boundary between platform-managed, privileged networking and ordinary app-managed networking.
WireGuard, OpenVPN, and other VPN protocols live and thrive in ordinary Android apps through `VpnService` without this platform integration. Currently, there are essentially four functionalities exposed to ordinary apps from the platform stack. The Binder total is 16 methods across three of these groups; the IKE library runs in the app process and adds no Binder surface of its own. This creates a weird hybrid structure.
The same general delegated-send architecture caused the past two major VPN leaks this year, although the QUIC delegated-send issue used a separate but closely related API rather than one of these four groups:
1. Applications may create transport-mode security associations and apply them to individual sockets. (9 Binder methods.)
This is technically the only one that provides any kind of additional functionality rather than a performance or provisioning convenience.
This is the functionality that would actually be lost. Applications that genuinely depend on the legacy API could either migrate to a supported userspace implementation or remain on Android releases where that API is available. It is not Google's job to support legacy technology forever. There are plenty of ways to keep using IPsec VPNs without these specific encryption protocols, so vendors would not need to perform a massive overhaul anyway.
But again, this is an extremely tiny set of users. I could not find any real, official proprietary application from a business that depends on this API. I found only two third-party apps that support the API, and it is almost impossible to find any business with an app that actually uses it. They would then, on top of that, also have to use this specific mode. The real number of users affected by deprecation is extremely low. I cannot even quantify it because there is not a single runtime data point to begin with.
2. The in-app-process IKE library, `IkeSession`. (No Binder interface of its own.)
It already runs in userspace and could, for the most part, be replaced with an app's own userspace IKE implementation.
The battery impact of two one-byte UDP keepalives per minute is negligible compared with many continuously running application activities, especially advertising and tracking libraries that regularly wake the device and perform background network activity. A continuously active tracker or advertising library can generate far more background network activity than these two keepalives per minute.
It would be nice to have, but for all VPNs and as a generic, separate API available only for active VPNs, not just weird hybrid IPsec VPNs almost nobody uses.
4. `Ikev2VpnProfile` management. (5 Binder methods: four change state and one queries it.)
This is only about profile management; it does not give the app direct control over the underlying kernel transforms. Users can enter all the information themselves in system settings.
It is a little inconvenient, perhaps, and currently some fields are not exposed in the UI, but this particular Android profile-management API never caught on to begin with and is now practically unused. So, it is fair to expect users of this practically unused API to spend one or two minutes entering their own profile data instead of using a proprietary app. However, I was not able to find a proprietary provider app that actually depends on it. It is unclear which provider actually uses automatic `Ikev2VpnProfile` provisioning.
This is also the exact reason why the NAT-T VPN leak happened in this API. The QUIC leak came from a separate but closely related delegated-send API. This is highly privileged machinery that would need a lot of refactoring before it could safely be provided to ordinary user apps. I assume they chose not to add proper safeguards because that refactoring was considered too costly. Developer time obviously costs money and is limited.
> (as someone from Google already suggested they're planning on doing)
> 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.
Security issues considered outside the scope of what they consider a security vulnerability are closed regardless of what they plan to do about the issue. Google primarily uses internal issues to track issues with Android. Public issues and security issues filed by external parties are only used to communicate externally and an internal issue is created for their actual issue tracking.
A security issue being closed means you aren't getting a bounty and it won't be fixed for existing Android releases. It doesn't mean it won't be fixed in a future Android release. They do track VPN leaks as issues internally and regularly ship fixes in new major releases. They unfortunately don't consider those security issues so they don't get prioritized. If they were considered security issues, then they'd likely consider them Low or Moderate severity which means those wouldn't be backported.
Only a large subset of patches for High and Critical severity issues are backported to older releases of Android. Low and Moderate severity issues stopped having patches backported years ago due to volume. High and Critical severity patch backporting is now being scaled down too due to AI accelerated vulnerability discovery. You need the latest yearly or QPR2 release to get full updates.
GrapheneOS has had to fix a bunch of VPN leak issues and we're in the process of fixing more of the issues. We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.
The GrapheneOS team did not respond to an email report either [0]. Does that mean we can draw similar conclusions from the GrapheneOS team? I don't think that would be fair or correct, so why assume malice from Google just based on the (lack of) response to the report?
N.B. I don't disagree there is a possibility of foul play on Google's part, but I think more evidence / better argument is required.
GOS explicitly stated that they work on a fix, also for other issues and they keep this on their radar.
Google just closed the ticket, without communicating their plan to deal with it. I just stated that we cannot rule out a possibility of foul play, thereby keeping other options open. Keeping that thing in mind which is better known as "the reality" I would be a little bit more wary about Google's stance towards privacy than I would be about GOS though. The difference in how these parties are handling this issue is already a tell.
There's a big difference between "the issue was closed" and "received no acknowledgment". The former is a deliberate action. The latter could be a case of SMTP-ate-my-email.
We passed it along to our developer working on solving VPN leaks. We didn't feel it was necessary to reply to a post linking to a public article. The article was shared with us by our users before we checked out emails.
We have a bunch of internally discovered VPN leaks which are already being worked on and this was added to that workload. We've already shipped a bunch of fixes and will ship more soon. We plan to eventually overhaul the whole system to prevent leaks in a much more systemic way.
Hello, original researcher here. I think part of the difficulty in discussing this issue is that GOS appears to distinguish between different classes of VPN leaks based on how they are triggered. In particular, VPN leaks caused by arbitrary user applications seem to be treated as less significant than leaks caused by race conditions or other behavior that users can trigger more directly.
That difference in prioritization has, in my view, made communication around the issue unnecessarily difficult. Some of the responses have also come across as defensive, as though raising additional VPN leak mechanisms somehow diminishes the value of the work already being done in this area. I do not think that is a productive way to approach security reports. Ideally, each issue should be assessed consistently on its technical merits, regardless of how closely it overlaps with existing work or who discovered it.
The original paper describing the NAT-T keepalive VPN lockdown bypass was published on July 29, exactly eight weeks ago. GOS has since stated publicly that the article had already been shared with them by users before they even checked my email about it, and that they passed it along to the developer working on VPN leaks. In other words, this has been on their radar essentially since the original publication, not only since the GitHub issue was opened several weeks later.
They have also been aware of the specific one-line mitigation since August 31, more than three weeks ago, and it still has not been implemented. Given how small and straightforward the mitigation is, I find that response time difficult to reconcile with the very strong criticism GOS regularly directs at Google and other vendors for slow security responses.
The issue has since received more than 200 points on Hacker News, so this is clearly not an obscure report receiving no external attention. Given that GOS was aware of the underlying issue essentially from the beginning, that eight weeks have passed since publication, that the concrete mitigation has been known for more than three weeks, and that the mitigation itself is a one-line change, I would have expected a substantially faster and more straightforward response. That seems particularly relevant given the standards GOS publicly expects other vendors to meet.
Issue could have been closed by a mis-click, an AI bot gone wrong, a misunderstanding of the issue etc. You can't assert it was deliberate unless e.g. you work in the team that handled it and have inside knowledge. Agree GOS should have benefit of the doubt (too)
> we cannot rule out that Google deliberately introduced or wanted to keep the leak in place
I'd say a lot stronger than "cannot rule out". Regardless of how it was introduced, if it is now known and the issue was closed without action, they are actively choosing to keep it.
Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.
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).
That seems like a good trick to me if you want to prevent people from installing spyware without any obvious signs.
You can almost hide the warnings (there's one small notification in the bottom of the notification tray you can't disable) and on some phones even the VPN icon, but you can't hide the new lock screen code your victim suddenly needs to enter to use their phone.
It used to be that Android showed random popups and notifications about identified security risks, which were awfully annoying if you have a private CA certificate installed. Luckily Google got rid of those.
In my experience, you can also set up biometrics on basically every phone, and Google has a few "don't lock the phone while it's with you in your pocket" like services you can optionally enable as well. Your backup PIN doesn't have to be four numbers, you can put a whole passphrase in there if you want it to be secure.
You could also do facial unlock. Less secure than Apple's implementation but more than good enough if you didn't have any lock screen set before that.
I already have a very long password. I object to unnecessary extra layers -- you can rely on secure hardware via the system if you must authenticate me again, but do not pretend to become your own steward.
Most of my apps that decide to ask for their own PIN (e.g. Klarna, Privacy.com, myFICO) have some deterministic garbage that's easy to guess because they provide no real security. I refuse to entertain security theater with real secrets. (real secrets = ones I don't remember)
Not every pocket thief or drunkard who finds your phone has cellebritr. Security measures consider the threat model.
More specifically, another commenter in this thread says it's to make sure the user is aware of the configuration of a VPN which, if done maliciously, funnels all your traffic toa a hostile place.
A pocket thief will bring the phone to a friend with a laptop and black market software. If the phone has no theft protection, they will factory reset it; if it has, they will use paid software to remove protection. I have not used that software and do not know if it is actual now, but Internet search shows that older phones are completely unlockable.
Good thing is that some of the aforementioned exploits can be used to work around locked bootloader and liberate the phone.
Do not rely on any security in Android. It has lot of mistakes, poorly coded high privilege vendor software, so it would be dumb to use it for anything valuable.
> More specifically, another commenter in this thread says it's to make sure the user is aware of the configuration of a VPN which, if done maliciously, funnels all your traffic toa a hostile place.
I do not see how PIN protects the user, especially if user had PIN before installing a malicious VPN. Also, isn't Google Play supposed to check every application for malicious functionality?
> 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.
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)?
>There is no update the GitHub issue for 2 weeks except for deleting a comment by the reporter yesterday.
Yeah, i was very confused by that, especially after they invited them to post publicly/privately. They love controlling the public communications when it comes to researchers. I remember ryrona, a guy who found VPN leaks, being censored for no reason whatsoever in their public GitHub issue tracker.
Original author here. I want to separate the technical work from the communication style. At one point I accidentally wrote Daniel's name as "Danielle." His entire response to one of my technical comments was simply, "That is not my name." I apologized, corrected the comment, and also made a point of acknowledging the quality of his work.
I think it was good that this exchange was later deleted, but it would have been better if the interaction had not gone in that direction in the first place. He appears to do strong technical work, and I do not want to diminish that. At the same time, some of his communication can come across as unnecessarily dismissive, confrontational, or unprofessional. That makes already difficult technical discussions harder than they need to be.
Most people I know use a VPN do it to bypass geo restrictions and/or get a discount with cheaper currencies. (But hey, our "representatives" seem to disagree.)
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.
reply