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

GrapheneOS finds Bluetooth memory corruption via ARM MTE

grapheneos.social

Post reply on HN
Print view View original

161–170 of 228 posts

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#161

Post by Sytten »

strcat wrote: post #110
Sytten wrote: post #6

Earlier quoted context omitted.

Agreed but they do drop support for older pixel devices very very quickly which is kinda of PITA. At least the Pixel 8 is supposed to be supported 7 years.

GrapheneOS provides extended support for end-of-life devices but we strongly discourage using our extended support releases. You can see we do that from https://grapheneos.org/releases and https://grapheneos.org/faq . We set an accurate Android security patch level field and do not downplay it with inaccurate claims about it. We do not do what other alternate operating systems by splitting out a Vendor security patch…

I understand that from a security perspective, but from an e-waste perspective even the current 7 years support is disastrous let alone the previously 3-5 years that vendors.

Not everybody has the same security needs, I often gift my older phones to my family members and if I have the choice to leave them on a fully unpatched device vs a GrapheneOS that is a "best effort" patch I will happily choose GrapheneOS.

I am super glad for all the work you guys do in any case, you can only love from me and I am honestly not buying an phone that doesn't support GrapheneOS at this point.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#163

Post by saagarjha »

mynameisnoone wrote: post #145

This is 2024. We need formally-verified operating systems, applications, and tools in the spirit of seL4 but going beyond it in rigor. Cobbling together lightly tested, over-engineered, heaving codebase systems with fragile, dangerous languages in this day and age is asking for users dying when foreign actors hack them, annoying bugs for many, and attack surface for malware and hacking generally. On top of that, clea…

I look forward to seeing your implementation of this :)

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#164

Post by saagarjha »

strcat wrote: post #98
loeg wrote: post #51

Earlier quoted context omitted.

The tradeoff isn't just memory use or performance -- it's also user-facing crashes that weren't present before. That is likely the bigger factor in deciding whether or not to enable the feature.

> The tradeoff isn't just memory use or performance -- it's also user-facing crashes that weren't present before. That is likely the bigger factor in deciding whether or not to enable the feature. We're only proposing enabling it for the base OS and user installed apps opting into it. Google has already fixed nearly all the crashes due to testing with HWAsan and MTE. They don't test enough with real world usage yet b…

I don’t understand your argument here. Google has been working on fixing the their own crashes with the data they have right now. Why would they turn it on for everyone else while they do that?

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#165

Post by saagarjha »

strcat wrote: post #113
loeg wrote: post #55

Earlier quoted context omitted.

On iPhone, it's called iOS. https://security.apple.com/blog/towards-the-next-generation-...

Pixels with the stock OS have comparable security to iPhones already. This thread is also about MTE which doesn't exist in Apple's hardware yet. The whole point of GrapheneOS is providing far better privacy and security than that baseline with features like hardened_malloc, Contact Scopes, hardware level USB-C port control, etc.

Apple hardware ships with MTE; it’s just not enabled.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#166

Post by gchadwick »

brcmthrowaway wrote: post #143

How does MTE compare to CHERI?

CHERI provides actual hardware enforced protection. MTE exists to find potential security bugs but no real protection. You've got a 4 bit tag, which an application can forge so if some attacker needed to forge the correct tag they could choose randomly and be right 1/16th of the time. The idea is when MTE is employed you'll get bad accesses occurring occasionally that aren't due to an attacker and don't actually cause anything bad to happen (imagine a typical buffer overflow, it may well be the words immediately beyond the end of the buffer aren't being but to any other purpose so using them actually works). MTE will detect these and they can be investigated and patched before they can get turned into a weaponised exploit.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#167

Post by chasil »

strcat wrote: post #150
chasil wrote: post #76

Earlier quoted context omitted.

Taking the "vendor security patch level" into account, it is impossible in some situations. If a critical vulnerability is found in a Qualcomm modem, wifi, or bluetooth firmware, there may be scenarios where this cannot be fixed at the OS level.

We have extended support for end-of-life devices but discourage using it and make it clear that it's insecure. We dislike needing to provide it and many people don't realize we do because we make sure not to hype it up and instead try to get people to move to secure devices with full patches available. 6th gen Pixels moved to 5 year minimum support from launch and 8th gen moved to 7 years so we do not think extended…

That is interesting and useful discussion.

I do wonder what I am seeing on Lineage with an older device, where the OS security is current, but the vendor security is long out of date.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#168

Post by VariousPrograms »

gspencley wrote: post #139
jacooper wrote: post #133

Earlier quoted context omitted.

Try disabling rerouting for Geolocation requests to GrapheneOS, because I personally found the gps provider integrated in it to be almost unusable, since it doesn't implement Bluetooth/wifi scanning at all. Yes that means google will get your location, but it's still better than going back to stock which is also better than any other third party skin in terms of privacy/security.

It's possible that there was something I didn't figure out how to configure correctly, but I spent a good chunk of time on our vacation mucking with various settings, including disabling re-routing location to the OS :/

I had the same experience with the Disney parks app not working properly at all on Graphene. Otherwise I haven’t had issues, even with other fitness/map apps that require GPS.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#169

Post by devit »

jetbalsa wrote: post #81
gausswho wrote: post #77

Earlier quoted context omitted.

I've been very happy with GrapheneOS on my Pixel 7, for the year that I've had it. The only inconveniences if you may call them that have been in alerting me of things naughty apps were doing. Actually, no. One problem I've had is that external audio input via USB has not worked for me. Anyone else figure that out?

Android Auto is not yet supported in GrapheneOS and that's pretty much half the usage of my phone gets on a daily basis

Android Auto support has been added recently and it seems to work well.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#170

Post by brcmthrowaway »

gchadwick wrote: post #166
brcmthrowaway wrote: post #143

How does MTE compare to CHERI?

CHERI provides actual hardware enforced protection. MTE exists to find potential security bugs but no real protection. You've got a 4 bit tag, which an application can forge so if some attacker needed to forge the correct tag they could choose randomly and be right 1/16th of the time. The idea is when MTE is employed you'll get bad accesses occurring occasionally that aren't due to an attacker and don't actually caus…

Google should use CHERI
Post reply on HN