> 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.
> 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.
> 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.
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.
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.
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)
Hello
Check: https://news.ycombinator.com/item?id=49096839
Please upvote/comment/share/mitigate
Best regards
Armin Šupuk
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.
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 know 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.
Google closes security issues when they consider it out-of-scope for a bounty. It doesn't mean they aren't working on a fix. They usually still fix the valid ones in a future major release but can take a long time to do it. They do not currently consider VPN leaks valid for bounties or backports to older releases.
They do ship VPN leak fixes in newer major releases and add tests for it. There are many other privacy and security bugs which are not backported to older releases. Only a subset of High and Critical severity issues are backported. That subset recently began getting much smaller due to AI accelerated vulnerability discovery which Google announced to OEMs.
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)?
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.)
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.
> We've made a post about it on social media as we've had to do before when this happens
That's not the full truth: you have ordered followers to brigade this community, in a disgusting breach of the rules and acceptable behaviour of this community. You ought to be banned immediately.
"If you have an established account on Hacker News, enable "showdead" in your settings, open our flagged posts and press "vouch" to help restore them"
("open our flagged posts and press vouch" is the imperative mood)
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.
>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.
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).
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?
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.
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.
> 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.
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.
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 to Google there.
57 comments
[ 367 ms ] story [ 257 ms ] threadGood guy Google, as usual.
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.
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.
[0] https://github.com/GrapheneOS/os-issue-tracker/issues/8617#i...
a person walks up to you, punches you in the face, and leaves.
it could have been an accident, an AI bot, or a misunderstanding. definitely not deliberate.
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.
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 know 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.
They do ship VPN leak fixes in newer major releases and add tests for it. There are many other privacy and security bugs which are not backported to older releases. Only a subset of High and Critical severity issues are backported. That subset recently began getting much smaller due to AI accelerated vulnerability discovery which Google announced to OEMs.
If you're right, you can sue Google and become a rich man.
I have a hunch this leak is bound to wifi hardware only, for details: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
Do any similar leaks exists on iOS currently?
some sites really really do not like my t-mobile wireless internet IP
I think it's because t-mobile uses a small pool of IPv4 but that's just a guess
I have to use cloudflare-warp to even get on their sites (it's a free VPN)
major sites too like adidas .com
See https://news.ycombinator.com/item?id=49672677.
That's not the full truth: you have ordered followers to brigade this community, in a disgusting breach of the rules and acceptable behaviour of this community. You ought to be banned immediately.
"If you have an established account on Hacker News, enable "showdead" in your settings, open our flagged posts and press "vouch" to help restore them"
("open our flagged posts and press vouch" is the imperative mood)
https://ibb.co/6J0CyVz6
It might help to ask moderation about this. Could be an artefact of brigarding or something similar.
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.
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.
Just to give an example, here is publicly available information: https://github.com/youngrichu/frp-freedom/blob/main/FRP%20By...
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?
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.
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.
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.
Google is Evil.
You might as well use Meta or Microsoft products. Or Phillip Morris.