Live data from Hacker News

Samsung Removes Bootloader Unlocking with One UI 8

sammyguru.com

241–250 of 254 posts

Re: Samsung Removes Bootloader Unlocking with One UI 8

#241

Earlier quoted context omitted.

Unfortunately, it's hard to make Fairphone secure. No separate secure element (so much easier to do brute force PIN attacks) and always lags in monthly security bulletin patches and major OS releases (remember that the monthly patches typically only address high/critical vulnerabilities, for the rest you need OS updates, QPRs, etc.). Until Graphene works out the deal with the OEM that they are talking to, Pixel is pr…

Does that mean Graphene plans to support phones from other manufacturers than Google?

Fingers crossed that's what it means and that it succeeds.

I'd likely buy that.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#242
post #192

Earlier quoted context omitted.

I don't understand your points, to my eyes if the bootloader is unlocked you simply either: - don't provide the features for which you require a locked bootloader - and don't do anything with the rest of the features And anyhow, I'm almost sure that this is AOSP code (with a quick search I didn't manage to find it). And, I don't know any carriers that require a locked bootloader outside of the US, and Samsung already…

You should read up a bit more on the matter then. The bootloader is not shipped in an unlocked state, even on a device which supports BL-unlock. Bootloader-unlock describes a feature which supports a controlled break of the trust-chain of the device, so telling the bootloader that it should continue executing the bootshell even if the signature check has failed. In this state the OS should continue to boot despite of…

Note that “applications should gracefully handle” does include “may opt to disable some or all functionality” here, in order to protect secure credentials, comply with merchant agreements, and so on. A productive example of this to study is how macOS behaves when secure boot is disabled, by disabling a couple specific attestation-mandatory features while leaving the majority of application functionality unaltered.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#243
This seriously pisses me off. We are literally watching the end of true ownership of our phones end right before our eyes, imagine if your laptop or new motherboard you purchased from MSI or whoever did the same and locked the bootloader to only allow booting official Microsoft-signed code (aka Windows only) and if you wanted to run Linux... sorry but no that's what we decided and we know better than you. Despite custom OS support being grainy in phones due to proprietary hardware and ARM chips, I really care about having the option to be able to do it (plus rooting with tools like Magisk is pretty universal across phones anyways since it lets you patch most firmware images).

It was already bad with Huawei stopping their unlock program and Google cracking down more on rooting by introducing strong integrity with their new Play Integrity API (which was an upgrade from the older SafetyNet API), basically meaning there is hardware security called the TEE (ARM TrustZone for most phones if you're interested in reading more) built into the ARM processor which "snitches? (lack of better word)" on you if the firmware booted no longer matches the manufacturer signed firmware, and causes you to fail strong integrity which means apps like bank apps can choose to deny you service (Google Wallet does this for NFC payments). There are workarounds which the custom ROM/root community still uses which mainly relies on older leaked cryptographic signing keys from the TEE being used which bypass the phone's TEE and sign the "integrity verdict" in user land to say "all is good" to Google, but Google can easily tell if these keys have been compromised since they track usage, and the storage of these keys just keeps getting better, getting as close to impossible as you can in a modern phone since to extract it would require you to quite literally de-lid the ARM chip and hope you don't break anything in the process while somehow extracting the key, in other words not feasible.

This is all great when it comes to security which Google and all manufacturers have been pushing on, but it comes at a serious cost of ownership, you cannot tell me we truly own our phones when we have literal hardware protection that, quoted right from wikipedia: "code integrity prevents code in the TEE from being replaced or modified by unauthorized entities, which *may also be the computer owner itself*". I don't know about you but a chip (and Google) that dictates what I can and cannot do with my phone doesn't sound like ownership to me.

All these recent changes and events sounds to me that Google is actively pushing and "encouraging" phone manufacturers to disable bootloader unlocking, we're constantly seeing manufacturers which were once before root and unlock friendly randomly changing their mind and quietly removing or severely limiting that feature in the background (Huawei, Xiaomi, now Samsung, etc). You have to remember these manufacturers won't back down from what Google tells them to do if it's for "security" since they're all in each other's pockets so they won't pushback without a good reason.

And if you want to use the typical excuse "allowing bootloader unlocking is unsafe", we've already proved it can work quite well while maintaining security as demonstrated by UEFI's Secure Boot which allows you to enroll custom boot keys (should you wish), while keeping some popular default keys such as Microsoft for Windows, and allowing you to lock the entire firmware config behind a password (which is stored in a security chip in modern motherboards so you can't use the old trick of removing the CMOS battery). That's more security than any regular citizen might need.

This TEE thing is all about control. Google and manufacturers don't like people installing custom firmware or rooting because then they can't keep you in their ecosystem to keep taking your data and hoping you eventually buy something from them. Some app developers also think this locking down of phones is great in order to protect their app against abuse than actually investing in good backend security which I just find to be hilarious.

I hope some laws get passed to protect us from the 1984 book that society is starting to become thanks to the government and corporate conglomerates themselves, although I sadly find that to be unlikely.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#244
post #69

Earlier quoted context omitted.

No secure element, no memory tagging support, no proper cellular baseband isolation, no verified boot, taking months to ship security updates .. the list is long. From a security/privacy perspective the fairphone is on the worse side of options unfortunately.

> no memory tagging support That's not a security feature though... We established that. Fair enough on the other points.

Memory tagging is an important security feature. The way GrapheneOS uses it is explained at https://news.ycombinator.com/item?id=44678704.

Only having 16 possible tags doesn't impact the deterministic protections we provide. One of the tag values is reserved for free data, internal metadata, etc. and can also be used as a form of 16 byte guard page. For heap allocation, we also dynamically omit the most recent adjacent non-free tags and the previous non-free tag for the current slot. There are 15 possible random values but 3 are dynamically omitted.

An attack often needs to use multiple invalid memory accesses where each one would have a 1/15 chance of success from probabilistic MTE alone. MTE gets combined with other probabilistic memory allocator protections. Our main memory allocator also has slot randomization and quarantine randomization.

A future revision of MTE could be easily be increased to 8 bits and it paves the path to having much larger memory tagging in the future too.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#245
post #126

Earlier quoted context omitted.

For people out of the loop, parent is referring to TikTag[0], a side-channel speculative execution attack breaking MTE in a probabilistic defense scenario, and the weird cope coming from some people that "MTE was only supposed to be a debugging feature anyway". However, you need some form of code execution beforehand already for this attack, and more importantly it doesn't affect any of the deterministic guarantees o…

> MTE was only supposed to be a debugging feature anyway It literally was. MTE is a padlock with 16 combinations.

https://news.ycombinator.com/item?id=44776816

Re: Samsung Removes Bootloader Unlocking with One UI 8

#246
post #169

Earlier quoted context omitted.

> MTE was only supposed to be a debugging feature anyway It literally was. MTE is a padlock with 16 combinations.

The number of combinations is irrelevant if you're not relying on randomness. Graphene sets the tag to a static value on deallocation[0] to prevent use-after-free, you don't even need to guess! The same is true for a lot of buffer overflows, as their allocator ensures two adjacent allocations have different tags, so unless the vuln allows you to skip ahead you'll always trigger a fault. [0] https://github.com/Graphen…

We use the standard reserved tag (zero) for freed data but we also dynamically exclude the previous non-free tag for the current slot and the most recent adjacent non-free tags (i.e. the current tag for the adjacent slots or the previously used on if they're currently free). This provides a lot of deterministic protection against use-after-free especially when combined with our quarantine. It provides full deterministic protection against small or linear overflows. The fallback to probabilistic protection with 15 random values is still very valuable and does not mean only lowering exploit chance to 1/15. An exploit can require multiple invalid memory accesses. Side channels for leaking tag values aren't inherently usable in every case and an attacker can't simply choose the memory layout.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#247
post #169

Earlier quoted context omitted.

The number of combinations is irrelevant if you're not relying on randomness. Graphene sets the tag to a static value on deallocation[0] to prevent use-after-free, you don't even need to guess! The same is true for a lot of buffer overflows, as their allocator ensures two adjacent allocations have different tags, so unless the vuln allows you to skip ahead you'll always trigger a fault. [0] https://github.com/Graphen…

Interesting, fair point! I guess it helps for vulnerabilities that don't allow pointer control (which is probably a lot of them).

MTE mainly exists to catch the initial memory corruption in the first place rather than to protect specific targets from memory corruption. The current limitation of only having 16 possible tag values makes the fallback to probabilistic protection fall weaker than it could be but it's still very useful and multiple invalid memory accesses are often required. An invalid read is protected against as much as an invalid write. ARM acknowledged the issue of side channels able to leak side channels in certain circumstances and that's being addressed for newer hardware. Bear in mind side channels can be used to directly leak sensitive data too and it's a huge class of issues not specific to memory tagging.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#248
post #23

The writing's been on the wall for custom ROMs in general for a while, so I've been starting to think about a mobile phone vendor I could actually have a decent business relationship with. I.e. use their stock ROM and be fairly happy with it. Any opinions? Samsung was a candidate for their somewhat unified ecosystem. Maybe even apple.

Samsung carries a lot of advertising crap, tracking, etc. Pretty much every phones is going to be worse than Pixel in that respect, since you get Google's tracking + whatever pile of crap the vendor added (which in the end they all seem to do). So it's basically: Pixel with GrapheneOS > iPhone >> Google Pixel with PixelOS I wouldn't recommend anything else. Theoretically Fairphone + e/OS may have been an option, but…

> Theoretically Fairphone + e/OS may have been an option, but the security is crap.

Lack of current privacy/security patches and the current privacy protections in Android means having very poor privacy too. There's no equivalent to the privacy protections added by GrapheneOS either including ones also offered by iOS now such as iOS having a more basic equivalent to the GrapheneOS Contact Scopes feature since iOS 18 and iOS having better storage/media control than Android similar to Storage Scopes in GrapheneOS.

> I guess there is Sony, you could even install Sailfish OS, no experience though.

SailfishOS is much less private/secure than AOSP and is largely closed source. It's the opposite of a more open OS.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#249

Pixel stopped providing device trees, kernel history, Samsung has been doing this for a while now. Which are the devices/vendors that still allow / encourage this? Even Graphene OS reported that they're in talks with some vendor... Have there been any updates towards that? The main reason i used to root devices are: * Get longer support/OS updates than what the vendor provided * System level adblock using adaway * Ti…

> Even Graphene OS reported that they're in talks with some vendor... Have there been any updates towards that?

The startup we were working with before went bankrupt. In June, we started working with a major Android OEM which has provided resources for identifying everything which will need to be done to meet our requirements and provide official GrapheneOS support. They believe they can meet all our official requirements without much trouble and they're going to determine how much resources they want to put into it soon. We don't yet know how many resources are going to go into it.

> The main reason i used to root devices are

Note using GrapheneOS does not involve rooting.

> System level adblock using adaway

You can use RethinkDNS for filtering combined with still using a WireGuard VPN or multiple chained WireGuard VPNs. Android has a perfectly good API for this.

> Titanium backup

GrapheneOS has a built-in encrypted backup system we plan to significantly improve upon. The basics are there already.

Re: Samsung Removes Bootloader Unlocking with One UI 8

#250

Earlier quoted context omitted.

Unfortunately, it's hard to make Fairphone secure. No separate secure element (so much easier to do brute force PIN attacks) and always lags in monthly security bulletin patches and major OS releases (remember that the monthly patches typically only address high/critical vulnerabilities, for the rest you need OS updates, QPRs, etc.). Until Graphene works out the deal with the OEM that they are talking to, Pixel is pr…

Does that mean Graphene plans to support phones from other manufacturers than Google?

Yes, but they need to meet our official requirements:

https://grapheneos.org/faq#future-devices

We're working with a major Android OEM and it's going well so far. It's still in an early phase where they've assigned a small amount of resources to it to determine everything which needs to be done and then make the case for a much larger investment of resources. We expect that to happen and for it to go well.

Post reply on HN