Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

arstechnica.com

Post reply on HN
Print view View original

351–360 of 372 posts

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#351

Post by strcat »

fph wrote: post #204
strcat wrote: post #149

Earlier quoted context omitted.

That's definitely not trivial and it's a small fraction of the security features GrapheneOS provides. https://news.ycombinator.com/item?id=45779157 explains several of the relevant features. Using hardware memory tagging for the whole base OS is definitely not trivial, and neither is implementing a much more hardened memory allocator. Our USB protection is not a trivial feature and is much more advanced than the USB…

I never wrote that the other Graphene OS features and mitigations are trivial. I agree that there is much more to that. And even if the USB mitigations were hard to write (thanks for all your work, by the way!), they are surely significantly easier to backport from an open source project.

Convincing people that the exploit protections are valuable and worth providing as even an opt-in feature let alone an enabled by default one is difficult.

Google shipped the Pixel 8 with production quality MTE support at a hardware level in October 2023 but still isn't using it by default and their Advanced Protection mode only uses it for a tiny subset of the OS and nearly no user installed apps. Enabling it would involve a whole lot of work fixing the bugs it finds, but we're already doing that work in GrapheneOS. They'd also need to fix several issues with their MTE integration in Chromium and elsewhere. It wouldn't be as good as our better implementation in hardened_malloc, etc. but they could be using it. They could start using it in full async mode for near zero performance and cost and then enable sync or asym mode for more components over time where the performance cost is irrelevant, which applies to most of the base OS. They might not want to use sync mode in the kernel for performance reasons, but other than that it mostly has no noticeable performance cost outside of apps.

Performance is likely a major factor Apple is not enabling it by default for apps and is instead discouraging app developers from opting into it by scaring them away with compatibility and performance concerns along with implying apps need to be written with it in mind which is really not the case. It finds memory corruption bugs and doesn't have false positives. Apps should not have memory corruption bugs in regular use and it's more than just an MTE compatibility issue if they do. Android made the smart decision to start tagging points with Top Byte Ignore in the system allocators many years ago which paved the way for HWASan support used by Android to nearly fully replace ASan and then later MTE support. HWASan is similar to MTE but with 8 bit instead of 4 bit tags using Top Byte Ignore but all accesses need to be instrumented to be checked since it's not a hardware feature. HWASan is much slower than MTE but Google has heavily used it for many years which means most of the OS was prepared for MTE other than hardware specific parts not well tested by automated testing.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#352

Post by Sanzig »

kube-system wrote: post #338
Sanzig wrote: post #325

Earlier quoted context omitted.

I'm not talking about installation. I'm talking about using the OS once it's installed.

It’s a distinction without a difference when Graphene is installed by zero OEMs.

I mean, I'm not sure what you expect the GrapheneOS project to do about that. I'm sure they'd love to provide hardware if they could, but they are a small nonprofit. They are currently working with an undisclosed OEM to to provide official support on an upcoming phone, which may lead to factory-installed options in the future if all goes well.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#353

Post by AlgebraFox »

tonydav wrote: post #303

I only wished they'd add Automatic call recording.

I am sure that will cause a lot of trouble in many countries. How hard is it to click Record button for the important calls? I don't think a small project like GrapheneOS should spend time on every small request users want.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#354

Post by astrange »

bitwize wrote: post #22
GeekyBear wrote: post #17

Earlier quoted context omitted.

No American company has a choice when the Feds want data stored on a company's server. That doesn't stop Apple or any other company from designing devices that attempt to keep prying eyes out of the data stored on your device.

The government has ways of twisting the arms of uncooperative people/organizations into providing all the backdoors they need. Everything from increased tax and regulatory scrutiny to "discovering" CSAM on executives' computers or phones. The government does what it wants because it's the government. Mere laws generally don't stand in its way for long.

Who is "the government" here? There isn't a single "the government" in the US.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#355

Post by astrange »

anonym29 wrote: post #198
GeekyBear wrote: post #29

Earlier quoted context omitted.

The government certainly objected when Apple designed an implementation of encrypted cloud backups for iDevices. That didn't stop Apple from eventually rolling out encrypted cloud backups anyway. Apple also refused to insert a backdoor into iDevices when James Comey ordered them to do so. They took the FBI to court and forced them to back down. Google is perfectly capable of fighting too, but their business model put…

Security theater for marketing purposes. End users have no way of verifying that their cloud backups are encrypted, and Apple is the same company that complied with the NSA's illegal, unconstitutional conspiracy to conduct warrantless bulk surveillance on American citizens and lie about it to congress: PRISM. Fortunately, no intelligence officials faced any consequences whatsoever for perjuring themselves to congress…

If you think Apple lied about this you can sue them for securities fraud, as it's illegal to lie to shareholders.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#356

Post by astrange »

immibis wrote: post #18
fluidcruft wrote: post #8

Earlier quoted context omitted.

Is there anything actually preventing Samsung or another vendor from adopting GrapheneOS's security innovations?

Probably their legal obligation to comply with secret government orders (FISA, NSL etc - the government probably already said don't make unhackable phones or else) and their informal wish to remain on the regime's good side.

Samsung is not an American company and what you're claiming would conflict with other countries' laws, namely EU Cyber Resilience Act.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#357

Post by Sesse__ »

strcat wrote: post #346
Sesse__ wrote: post #223

Earlier quoted context omitted.

What data _is_ there to extract BFU, really, if you can't break the secure element? I mean, the main storage isn't decrypted yet, right?

Android and iOS both use filesystem-based disk encryption with fine-grained keys, not only a global encryption key. There's a subset of the OS data available before first unlock to have basic functionality available there. Three examples are installed apps, saved Wi-Fi networks including passwords and alarms with the system clock apps being available before first unlock via explicitly storing it in the before first u…

Thanks! So you will indeed get a small amount of data, but nearly nothing tied to a specific user profile.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#358

Post by angry_octet »

tranq_cassowary wrote: post #135
LoganDark wrote: post #78

Earlier quoted context omitted.

GrapheneOS makes security trade-off that are inconvenient to the user. This results in a far more secure device, but nonetheless a device that the general public would find far more annoying. Google would lose a proportion of its user base by implementing the same protections. Example: https://old.reddit.com/r/GooglePixel/comments/ytk1ng/graphen... Also Google Pay is missing.

Google Wallet works but tap-to-pay NFC payments don't because Google enforces strong Play Integrity for that portion. They only allow Google certified OSes to use it. It's a sad choice on their part, not GrapheneOS' fault or choice.

"enforces strong Play Integrity" is just a nicer way to say that they use their market position to stop other ecosystems developing.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#359

Post by subscribed »

chasil wrote: post #333
subscribed wrote: post #324

Earlier quoted context omitted.

Vanadium is pretty good but I agree there are problems I can circumvent only by using another one (Brave); I presume it's the strict tracking protection that breaks some sites. Not sure about your launcher problem, but you had to turn it on yourself? I don't experience anything like this on my phones. I miss Nova though; none of the other launchers I tried came near (last tried: uLauncher, Kvaesito, Olauncher, Lawnch…

I understand that Magisk can be applied to Graphene if the final device lock step is not applied. I might try that if I elevate it to my daily driver. I'm not comfortable without root. I have the absolute right to have root on my device. I don't know why Graphene didn't just take Trebuchet.

> I understand that Magisk can be applied to Graphene if the final device lock step is not applied

Unless you relock the bootloader you are forfeiting major avenue into your phone (and it's not really, fully GOS - because you keep most important protections off).

But it's your choice of course. You'd be probably better off just creating your own OS image with preinstalled root libraries, etc.

> I'm not comfortable without root. I have the absolute right to have root on my device.

I agree with you fully. This is your phone.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#360

Post by subscribed »

mike_d wrote: post #337
subscribed wrote: post #260

Earlier quoted context omitted.

Not really. iOS in lockdown mode has multiple features disabled (or crippled, depending on how you look at it), while GrapheneOS is just..... secure by design with secure defaults. https://support.apple.com/en-us/105120 In iPhone also you cannot just turn on/off/adjust these protections one by one, it's all or nothing.

> OS in lockdown mode has multiple features disabled [...] while GrapheneOS is just... ...disabling features. Android Auto, Google Pay, enhanced GPS, SafetyNet, push notifications, support for any apps requiring device integrity, etc. They aren't redesigning and re-implementing these features securely, they are reducing attack surface just like lockdown mode.

>> [...] while GrapheneOS is just... > ...disabling features. Android Auto, Google Pay, enhanced GPS,

This is broadly false, not just misleading but false. - Android Auto: working wired or wireless without problems - Google Pay: app vendor choice to put it behind DEVICE_INTEGRITY check, not OS vendor. NFC payments work just fine with other vendors. - enhanced GPS: whatever that means, is most likely false. Users don't experience any issues with GPS

> SafetyNet

SafetyNet Attestation API is deprecated and no longer available so also not true. But from the context I think you meant Play Integrity API.

This is Google Services feature, not AOSP feature. GrapheneOS is an AOSP-based system.

GOS passes MEETS_BASIC_INTEGRITY. It doesn't pass DEVICE_INTEGRITY because it doesn't run privileged, unbound Google Surveillance Services (according to Google 10 year old phone not updated for 8 years is more secure as long as it allows Google Services sniff everywhere). It cannot pass MEETS_STRONG_INTEGRITY they way Google requires it because AFAIR that thing is signed by the TPM. It does provide an alternative STRONG_INTEGRITY assurance based on the AOSP Hardware Attestation API (which many developers in fact use).

> push notifications,

This is so false it should be called out as a lie, not just a falsehood. Reliable push notifications are supported both in the standard way (if user decides to do so), via GCM, or in one in the alternative ways, for example UP, exactly like on the standard Android phone.

> support for any apps requiring device integrity, etc.

This is also a lie or ignorance. See above. For example Starling Bank has explicitly implemented GOS Hardware Attestation API.

> They aren't redesigning and re-implementing these features securely,

What do you mean?

hardened_malloc? Memory tagging for entire kernel? automatic switch to BFU after timeout? USB data blocked by default with the screen locked? Network permission toggle? Storage/contact scopes? Critical patches released seemingly _months_ before the major vendors?

LOL. Half of your claims are either lies or misrepresentation.

The other half (Google Pay and Play Integrity) are vendor functionality. They would have to spoof (fake) it - exactly like rooted phones do (and which can often be detected). Or allow Google in the privileged mode, which is not going to happen.

That has been explained by the development team _so_ many times already.

They cannot "re-implement" a feature that *GOOGLE* offers to the developers using *Google store*. That would for example require using leaked private key. They are challenging Google's stance on Play Integrity with EU commission, because there is no technical reason to bar the safe hardware+OS passing a standard AOSP hw attestation.

This is an AOSP OS, not a hacked Google Pixel ROM.

> they are reducing attack surface just like lockdown mode.

They are reducing attack surfaces without locking down functionality. Google deciding to not support the competition is not GOS locking somehow down.

Entirely different from Apple's lockdown mode. QED.

I wouldn't mind listing _downsides_ of using GOS as a first/main device (because there are many), but I prefer facts over confabulations :)

Post reply on HN