- > Because system_server operates with elevated networking privileges and is exempt from VPN routing restrictions
So a VPN isn't a VPN on Android? Regardless of this bug. Do other locked down operating systems act the same?
by idovmamane
1 subcomments
- The technical detail that makes this egregious is that the leak happens in system_server, a privileged process. Android’s
own lockdown mode explicitly promises that no traffic bypasses the VPN. When the system itself sends the packet over the physical interface, that promise is broken at the kernel level, not in userspace. Calling this “not security bulletin class” is hard to defend.
by bastard_op
1 subcomments
- Just like manifest v3, it's not in their best interests to disallow snooping. It hurts their business model.
by unethical_ban
7 subcomments
- I know there are bad business reasons, but how can someone classify a VPN leak as "not a security issue" and keep their pride?
by bastard_op
1 subcomments
- Even more so, just like meta removing end to end encryption.
"Nah dog, we like watching everything you say and do."
- Side question: what's a good way of getting a GrapheneOS phone?
I have been interested in using GrapheneOS but hesitant about actually getting a Pixel phone. Used phone prices are usually >$300 even for "a" series unless I go back several generations. Whether the device bootloader can be unlocked is also a question. I am definitely not ready to spend $449 on a new Pixel 10a.
- > Google maintained its position, authorizing public disclosure on April 29.
I'm surprised they honored the embargo at that point, and delayed the fix until May. Why not just release immediately?
- I bought a used Pixel 6 for cheap to try out grapheneos. Can't say I like it. UX of lineageos is much better. There is a weird russian doll kind of situation with the package managers going on. There is one builtin "App Store" with only a few basis programs, one of which is another package manager, accrescent, which offers a few more apps, but still not comprehensive at all, so another package manager is needed for which grapheneos people seem to favor obtainium over f-droid, which I find is another strange decision. I much prefer a fully OSS package manager and there is real value in having people compile from the sources externally, maybe even reproducibly so, instead of trusting the github packages. The grapheneos security model seems oddly centralized to me. I can't really comment on the reported privacy and security benefits.
- Stock Android is spyware and adware, back in the day we called such software malicious and removed it, now it's the default.
by 1vuio0pswjnm7
4 subcomments
- "In its latest release, GrapheneOS says it has "disable[d] registerQuicConnectionClosePayload optimization to fix VPN leak," effectively neutralizing the attack vector on supported Pixel devices."
"GrapheneOS responded by disabling the underlying optimization entirely in release 2026050400."
GrapheneOS "fixed" the leak by disabling the optimisation
Some HN commenters in the past have praised QUIC and downvoted comments that questioned who QUIC stands to benefit the most
Using QUIC may serve the interests of others but for me the tradeoffs are not worth it; I block QUIC traffic
QUIC is sometimes on by default in software distributed by Google, like Android, and in some cases there is no option to disable it
by ignoramous
1 subcomments
- The issue reported on lowlevel.fun [0] and discussed on GrapheneOS forums [1] does seem like a security issue. It isn't clear why engineers in charge would mark it infeasible as the breach demonstrates more than one failure.
1. A new (albeit "hidden" [2]) network API registerQuicConnectionClosePayload(fd, payload) lets a process set any byte array for the OS to send on its behalf.
2. No ("panaroid networking") permission checks against the calling uid/process when sending that byte array out on a OS-owned UDP socket.
3. Bypassing ("panaroid android") permission checks [3] by simply calling network-related syscalls (or libc/bionic functions) as opposed to Android SDK APIs.
These steps essentially amount to app sandbox escape (2,3) and privilege escalation (1,2). I am utterly confused why the Android security team at Google won't take this more seriously.
[0] https://lowlevel.fun/posts/tiny-udp-cannon-android-vpn-bypas...
[1] https://discuss.grapheneos.org/d/35152-android-always-on-vpn...
[2] In as much the code mmap'd into your own process can be "hidden" away. For their exploit though, the author cleverly abuses Binder IPC primitives to reach the "hidden" parts.
[3] This bypass probably only works for this one scenario because of #2.
- Great, now to go and buy a Google phone so I can use it.
- [flagged]
by nunobrito
7 subcomments
- [flagged]
Hacker News