Android NAT-T keepalive offload bypasses VPN lockdown (supuk.ch)
jeroenhd 7 hours ago
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.
ValdikSS 6 hours ago
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.
brinepot 16 hours ago
grapheneos 12 hours ago
exceptione 12 hours ago
> 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.grapheneos 11 hours ago
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:
That account should clearly be banned rather than a subset of their posts getting flagged. The same applies to several other blatant ones.
exceptione 18 hours ago
codedokode 8 hours ago
driverdan 7 hours ago
codedokode 7 hours ago
unethical_ban 7 hours ago
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.
codedokode 5 hours ago
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?
jeroenhd 7 hours ago
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.
exceptione 19 hours ago
> 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.jjav 18 hours ago
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.
grapheneos 12 hours ago
gib444 16 hours ago
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...
nvme0n1p1 16 hours ago
gib444 15 hours ago
kennethkl 14 hours ago
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.
grapheneos 12 hours ago
Hello
Check: https://news.ycombinator.com/item?id=49096839
Please upvote/comment/share/mitigate
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.
nvme0n1p1 11 hours ago
exceptione 16 hours ago
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.
grapheneos 12 hours ago
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.
nonamesleft 18 hours ago
exceptione 18 hours ago
I have a hunch this leak is bound to wifi hardware only, for details: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
aucisson_masque 21 hours ago
Good guy Google, as usual.
grapheneos 12 hours ago
dingdong2026 4 hours ago
Google is Evil.
You might as well use Meta or Microsoft products. Or Phillip Morris. Blame yourself for the fallout.
potatoproduct 16 hours ago
TutleCpt 16 hours ago
gib444 17 hours ago
Do any similar leaks exists on iOS currently?
gib444 13 hours ago
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.
innocent_name 8 hours ago
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.
tosti 16 hours ago
gib444 14 hours ago
An individual: you're a pedo if you use a VPN
Give over.
tosti 13 hours ago
ck2 8 hours ago
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
orbital-decay 5 hours ago
folienumero 4 hours ago