←back to thread

455 points akyuu | 1 comments | | HN request time: 0s | source
Show context
derbOac ◴[] No.45766747[source]
They couldn't answer the question most on my mind: "We’ve reached out to Google to inquire about why a custom ROM created by volunteers is more resistant to industrial phone hacking than the official Pixel OS. We’ll update this article if Google has anything to say."
replies(10): >>45766778 #>>45777056 #>>45778032 #>>45778056 #>>45779079 #>>45779102 #>>45779404 #>>45780503 #>>45781099 #>>45783125 #
IncreasePosts ◴[] No.45777056[source]
Is grapheheOS actually harder to hack or does cellebrite just not put a lot of effort into supporting it because the very low odds of LEs running into one in the wild?
replies(5): >>45777082 #>>45777144 #>>45777155 #>>45779084 #>>45779157 #
markus_zhang ◴[] No.45777082[source]
I read from an old HN post that three letter agencies hate graphen OS. The author heard it from defcon or some similar conference. I couldn’t find the post anyway :/ I think it is buried under one of the posts that discuss Defcon and Blackhat.
replies(1): >>45778143 #
overfeed ◴[] No.45778143[source]
Wouldn't it be a total mindfuck if it turns out that Graphene is less secure[1] than stock Pixel, and this is all part of an ANOM-style honeypot operation that has Feds hyping it up, to trick interesting targets into adopting a less-effective security posture.

1. Such as via slower 0-day responses, for instance. This is a thought experiment, I'm nor alleging that this is what it is.

replies(9): >>45778164 #>>45778257 #>>45778894 #>>45779099 #>>45779207 #>>45779908 #>>45779962 #>>45780866 #>>45783723 #
Andromxda ◴[] No.45779908[source]
GrapheneOS releases patches very quickly, often even faster than OEMs do. But patches are only useful for fixing individual known vulnerabilities. GrapheneOS additionally focuses on defending against whole classes of vulnerabilities. [1] For example, in addition to fixing memory corruption bugs in individual system components, GrapheneOS has deployed memory protections for the entire OS in the form of hardened_malloc [2] and by enabling the ARM memory tagging extension for the kernel, most system processes (with very few exceptions) and all user-installed apps.

The honeypot theories don't make sense, since GrapheneOS is fully open source, and very transparent about developers, funding, infrastructure, and other internal stuff.

[1] https://grapheneos.org/features#exploit-protection

[2] https://github.com/GrapheneOS/hardened_malloc

replies(2): >>45780184 #>>45780685 #
Yokolos ◴[] No.45780184[source]
Reminds me of that one case a few weeks back where Graphene wasn't allowed to release a patch because Google wasn't planning on releasing a patch for it for a few more months.
replies(1): >>45781089 #
linux_modder ◴[] No.45781089[source]
GrapheneOS has a security preview release channel that is opt-in but includes patches from these embargoed vulns already. Again, it's opt-in but for those with a higher threat model use-case it's nice to have.
replies(1): >>45782777 #
largbae ◴[] No.45782777[source]
Would this not defeat the purpose of responsible disclosure? As a bad actor I could learn of secret vulnerabilities from this channel.
replies(2): >>45783767 #>>45786187 #
1. udev4096 ◴[] No.45783767[source]
You have google to blame. GrapheneOS tried very hard to make sure they have those security patches as google delays publishing the source tree and it's only available to OEMs