GrapheneOS fixes Android VPN leak Google refused to patch(cyberinsider.com) |
GrapheneOS fixes Android VPN leak Google refused to patch(cyberinsider.com) |
So a VPN isn't a VPN on Android? Regardless of this bug. Do other locked down operating systems act the same?
Mullvad and others reported on that one ages ago
It's a concern to me, because humans often extend their trust to computer trust based upon misunderstanding of the identically spelled words and lack of recognition of differing context.
VPNs, at least originally, were designed to provide access to private/business networks across another network. Office to office, home to office, that sort of thing. VPNs were only later turned into some kind of (supposed) security tool.
If your take on VPN code is "as long as your phone can reach the office printer over 5G" then this is a tiny bug. QUIC connections aren't being shut down properly, like they weren't before the introduction of the feature.
If your take on VPN code is "this wireguard tunnel must keep my identity safe no matter what" or "my security relies on this wireguard tunnel being an exact copy of all traffic exchanged over the internet" then this is a massive problem.
I don't think Android VPNs, or any VPN to be honest, were ever designed as a privacy or security measure. Especially not against apps with code execution on the device. The device itself will do all kinds of network interactions, some happening from within the modem chip itself.
Closing the bug was a mistake on Google's part, but I can see why they don't consider this a security bug in their bug bounty programme.
Step one… completely reform MBA programs.
If you patch it, you'd need to find another way to de-anonymize those users.
I feel like this should be toward the top of the terms of service for the phone, even above the mandatory arbitration clause.
What planet are you from?
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.
See, mobile phone vendors have their hands tied - they can offer bootloader unlocking, but they can't touch Google spyware, otherwise they won't be "certified", won't be able to use Google Play or even the name Android.. That's of course not enough for Google, they also want to go after users which of such systems / modified systems (with unlocked bootloader) - that's what "Play Integrity" is about, they work hard to make sure the phone gets as useless as possible.. Together those two basically prevent vendors from making the mobile privacy landscape any better.
In the EU, we should outlaw Play Integrity first, by mandating that security level attestation might only be done in a way there's an independent auditing body that might certify alternative operating systems (these could use standard Android attestation) based on objective security criteria, not the Google spyware criteria. I heard about the "UnifiedAttestation" initiative but I'm not sure what's the progress on that.. not that I'm a fan of attestation at all, but you need to understand that it's a different thing when you attest the security model of the system, and a different thing where a system being "secure" actually implies Google spyware must be installed. For banking apps, I'd just want a secure OS, like GrapheneOS - without GMS.
Howver, the main antitrust investigation should happen in the US, only US courts can bring relevant Google executives to justice.
"Nah dog, we like watching everything you say and do."
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.
I'm surprised they honored the embargo at that point, and delayed the fix until May. Why not just release immediately?
"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
GrapheneOS also has fixes for around 5 other VPN leaks and more fixes on the way. Android currently implements VPNs in a way that's prone to leaks due to VPNs being per-profile but profiles not using their own network namespaces yet and also depending on central services for the DNS resolver and various other things which have to properly handle VPN support. We have plans to improve the VPN architecture in the future to make it very resistant to leaks. There will also be support for running apps or groups of apps in VMs which can have even stronger protection against it.
QUIC as it is is brilliant, and this is not a feature of the protocol, it's a feature of the surveillance OS (Google's Android).
Other than that I checked on the OS before the latest release, and it didn't work anyway.
So just download f-droid yourself? Why the fixation on having a definitive, preloaded app store?
>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.
Operating an app store is almost as much work as maintaining an Android fork, and it's hard to fault the authors for not sinking massive amounts of effort into doing it, when there's already f-droid, play store (plus aurora store), obtanium, and many others.
Also Neo Store, Accrescent
Out of the box it has only a launcher and the minimal OS. All the minimalist needs.
If you want more, you get to decide where to go for that.
I call it empowering users, you call it inconvenience, but maybe in that case it's not the best OS for you?
GrapheneOS has the "App Store" to get the most basic apps required for general usage. Accrescent is distributed there because it follows Android's security baseline for being an actual app repository while F-Droid and Aurora Store do not. There really isn't a value in having third parties compiling apps to check for any malicious activity, which F-Droid does. These checks are not reliable and have been bypassed. It's one of the reasons why Wireguard is no longer on F-Droid. If you don't trust an app enough to get it directly from the developer, then don't use the app at all. The privacy and security benefits of GrapheneOS are supposed to be nearly invisible to the average user. Examples include a hardened memory allocator and memory tagging extension to protect from memory corruption bugs, and the ability to install sandboxed Google Play to use Google services without Google having complete control of your device.
Developers are not geniuses at every aspect of security or app deployment. They can sell their projects. Get compromised. Or can get tricked like the xz exploit
Having an app store making any effort to prevent or correct problems, especially as transparent as F-Droid, is better
Wireguard app dev wanting to bypass the store and push an executable to your phone every day is ridiculous. No user of app/package manager expects it to be bypassed
GrapheneOSs App Store is present to fulfil the role of the first party appstore that AOSP requires. It also serves to provide updates to first party apps out-of-band, and mirror apps for various case-by-case reasons.
Accrescent is mirrored due to it having a focus on privacy and security. It is currently in alpha and app submissions are closed. They will be open Soon:tm:.
Google play is mirrored for app compatibility with apps that require google play, and for access to the playstore.
The GrapheneOS community favors Obtanium due to its ability to fetch developer-signed apps from places like Github. Fdroid signs and builds nearly every app on the main repository with outdated build infrastructure and poor moderation.
GrapheneOSs security model inherits and builds upon the AOSP security model.
You're safer using a standard Android phone than using an OS as duct-taped together as CalyxOS.
CalyxOS is not a private or secure operating system. They have added several 3rd party apps and services, which includes several 3rd party connections. On top of this, several of these services are given problematic, privileged access.
A notable example of this is Android Auto. CalyxOS grants substantial privileged access to this component by default, while GrapheneOS sandboxes it, and exposes 4 opt-in toggles for privileged access. The user may granularly decide what privileged access they wish to grant.
Can you even lock the bootloader on your device? [2]
[2] calyxos.org/lock
The all apps stemming from app stores in the builting App Store is to provide a minimalist experience by default whilst keeping google play apps accessible. GrapheneOS has a majour focus on accessibility. They avoid users having to be technical to install an app store to get their apps.
Side note: I did get the 10a on launch from Google Fi for ~300.
Basically, buy a Pixel 6 or later (I suggest Pixel 7 or later, since Pixel 6 will be minimal support soon) that you are sure has an unlockable bootloader. The majority you'll see don't have an unlockable bootloader.
Which mostly means either buy direct from Google, or buy one on eBay that already has GrapheneOS/CalyxOS/LineageOS on it or for which the seller expressly says it has an unlockable bootloader.
(IME, don't bother trying to ask a seller to check bootloader, if they haven't already said. Almost no one is going to go through the process to check, the answer is probably no anyway, they might misunderstand your question and answer that it's "unlocked", and they may be tired of people asking.)
https://www.zdnet.com/article/my-sleeper-phone-deal-for-prim...
Used is a gamble due to improper OEM unlocking practices, so make sure it has a good return policy and try to verify OEM unlocking is accessible if you purchase used.
Yeah, do that.
It’ll still be the snappiest phone you’ve ever used.
Force “most” traffic through VPN using includeAllNetworks Yes, but imperfect (normal) Yes (supervision)
stronger controls are tied to device management / supervision, usually for organization-owned devices.
https://developer.apple.com/documentation/NetworkExtension/N...
Care to source this claim?
Haven't bought one (yet - but did quite a bit of research but again outdated by 2 years...)
Then I decided everyone who knows about bootloader unlocking would've already checked and mentioned if it was unlockable (but not if it wasn't, since why confuse normal buyers with a fringe thing), and I've never gotten a positive response trying to tell any seller about it, so I think I'm just wasting everyone's time.
Your mileage may vary.
https://old.reddit.com/r/CalyxOS/comments/1t3tdt6/calyxos_pr...
The problem with lagging is that only some of the security patches are backported to older androids, so the project would have to backport remaining ones themselves. Let's be real, no one does that in CalyxOS for all the supported devices.
Out of their 15 supported "modern devices" 10 are pixels.
Their extended support phones (6 devices) has three pixels as well. Might as well get more modern and secure OS instead (A16 with fixes and working call recording for example) :)
GrapheneOS has a requirement of a 5-7 year support window from an OEM.
Their partnership with Motorola, I think, involves some ability of Graphene OS devs to access/harden/update the firmware, but I'm not 100% sure. Firmware on phones, especially for the baseband processor, often involves a nasty confluence of copyright, trade secrets, patents, and government rules/demands.
But it is vastly uneconomical, and I doubt anyone is going to start doing it regularly.
We really need some kind of regulation demanding firmware support for longer. The EU seems the most likely entity to achieve something like that. Phone vendors can't even control how long they support their own hardware, because the SoC is almost always Qualcomm, and once they drop support, there aren't any good options left.
Luckily, Google's support periods are actually quite long, and very clear (stated on the website on launch date, unlike iOS or even Windows these days).
For the reader: look at things like LineageOS for the usecase of using things past official support period!
Librem says the Liberty phone is the same, it just costs more because it is assembled in the U.S. for people, companies, or governments that don't want it intercepted and modified by a bad actor.
No, they ported a new major Android release beyond what the SoC officially supported. They had already stopped providing firmware, kernel or driver security patches long before that point. They did what LineageOS regularly does by porting a new major Android release to hardware not officially supporting it. Unlike LineageOS, they had to convince a company to certify it as meeting the CDD/CTS requirements. Most OEMs including Fairphone have major CDD/CTS violations but yet still get certified in practice so that doesn't really mean as much as you'd think. It's common for Android OEMs to break functionality tested by the CTS and yet somehow they have certification. This is part of why the Play Integrity API's flimsy justification for the highly anti-competitive approach it uses is such nonsense.
Even the Fairphone 5 already lacks standard Linux kernel security patches due to having an end-of-life kernel branch. Fairphone doesn't provide anything close to proper updates.
Qualcomm offers up to 8 years of major Android version updates and basic security patches for their firmware and drivers. They charge money for each year of support. It's there if OEMs are willing to pay for an up-to-date SoC and pay for many years of support.
Why no hardware upgrade after 7 years?
Also this: https://puri.sm/posts/the-danger-of-focusing-on-specs/
Having a technical possibility to lock down GNU/Linux phones in principle in undefined future by undefined entity that doesn't even produce them yet is a FUD argument.
There is already a way to do this. It's fiddly, but not by much. Once set up it's a much better experience, though.
https://www.matteralpha.com/how-to/how-to-use-home-assistant...
What’s most glaringly missing, for you specifically, from the plethora of options available?
It seems like plenty of options are getting 7/10 things right.
Your best bet for now is to buy a new Pixel direct from Google, or a used one from eBay that the seller advertises as already having GrapheneOS on it (or otherwise guarantees that the bootloader is unlockable). These ones are worth a lot more than the ones that can only run Google/carrier Android.
https://grapheneos.org/install/web#prerequisites
I own two GrapheneOS Pixel 7 units, which should get any Google blob security updates (which GrapheneOS incorporates) through October 2027, and GrapheneOS may still support it with source updates after that. So in a year or so, I might get the GrapheneOS Motorola if it's available, or a later Pixel. (I never buy these new, since I don't want to carry a several hundred dollar phone when a 2 gen old one is still great, thanks to GrapheneOS.)
I also did the math and determined buying a new unlocked phone outright on this plan was far cheaper than paying Verizon monthly for one.
On any plan.
There’s a reason that as soon as you walk into a cell store they immediately try to schmooze you into signing contracts and leasing phones.
It’s the way they make the most margin!
Currently running my Pixel on Warp (Verizon) with zero practical difference, and starting Monday I'll also have a backup iPhone with a small $8/mo Darkstar line. The money I've saved since switching more or less paid for the iPhone, and I'll be getting 2x reliability for way less ongoing cost. The better app/website/support and extra features are just a bonus.
Google's Pixel hardware division likely operates at a loss - or breaks even.
and even if every active HN user bought $100-$400 used Pixels from Swappa, meaningless money to them.
Also, even Pixel 9a has all the security functions of the flagship that many other Android phones do not have or are just getting, such as the Memory Tagging Extension (MTE), the Titan M2 security processor (no need to rely on TrustZone for secrets), etc.
On a technical level, yea, it may be great hardware but in practice, I don't think it is. As an Android user, I wish it were but it's not. Samsung is so much more reliable as an end user (even with their own issues).