Security implications of leaving "OEM unlocking" enabled

DeletedUser564

Just out of interest...
I was wondering which security implications exist when "OEM unlocking" stays enabled after installing GOS.

As I understand there is no way to boot another recovery or modify the installed system on Pixel devices with a locked bootloader without triggering the automatic wipe of the device beforehand.

So the only problem might be, that somebody could erase the device or am I missing something here?

Novalissoide

DeletedUser564 https://grapheneos.org/install/web#locking-the-bootloader

Novalissoide

DeletedUser564 oh, I missed that the bootloader was still locked. My bad.
Yes, not as dangerous as an non-relocked bootloader, but still not recommended.

de0u

DeletedUser564 So the only problem might be, that somebody could erase the device or am I missing something here?

Somebody with physical control over the device for 20 minutes could re-flash the device with an OS that would capture the PIN/password and transmit it. The user would presumably quickly detect that this had happened, but if the PIN/password were in use elsewhere that would be a problem. And it is possible that there are other implications.

Overall it seems clear that if the privacy of the information of the device is a primary concern then leaving OEM unlocking off is better.

raccoondad

DeletedUser564 As I understand there is no way to boot another recovery or modify the installed system on Pixel devices with a locked bootloader without triggering the automatic wipe of the device beforehand.

You may not be able to alter the android systems disk data without having it fail to reboot, but you can edit user data still, or use exploits to gain root and act in memory only.

This is a major reason why auto reboot exists, to clear memory and revalidate the OS

spl4tt

I think the problem with that is, that you have to have dev options enabled for it.
Dev options are said to be unstable, and is recommended to be turned off.

So yea, I can't say if OEM unlocking is really a security concern on it's own, but I wouldn't trust it. Just turn it off.

Why do you even want it to be on? There's literally no use?

Novalissoide

spl4tt Developer options is in this case minor. Verified boot goes out the window, thats the big NO NO

fid03

spl4tt I think the problem with that is, that you have to have dev options enabled for it.

Not really. In the setup wizard after booting into the OS for the first time, you can simply uncheck the option to disable it. That won't enable the developer options menu.

DeletedUser564

de0u I understand. This is a real point. An attacker could steal the PIN with this. If it's not used somewhere else there would be no harm, because dumping the device before reinstalling the OS is impossible because of the forced wipe.

de0u

DeletedUser564 I guess developer options are OK, because they are open source and checked by many people including Google and have gone thru a decade of optimization.

They are "ok" if a device is used for development (that's what they're intended for).

Neither Google nor anybody else guarantees that developer options are "ok" for a daily-driver device containing data one wishes to be private and reliably available. Some of them absolutely increase attack surface.

DeletedUser564

de0u They are "ok" if a device is used for development (that's what they're intended for).

Neither Google nor anybody else guarantees that developer options are "ok" for a daily-driver device containing data one wishes to be private and reliably available. Some of them absolutely increase attack surface.

OK, lets say OEM Unlocking was the only changed setting in dev options. Still a problem?

de0u

DeletedUser564 [Let's] say OEM Unlocking was the only changed setting in dev options. Still a problem?

The OEM unlocking developer option is intended for flashing a development device. Obviously GrapheneOS users need to turn it on while flashing a device for production use. But, as described above, having it enabled is less safe than having it disabled. I presume that's why the GrapheneOS installation process encourages disabling it.

Obviously each user will do whatever might seem appropriate given any particular circumstances. But that doesn't mean that the GrapheneOS project, or users on this forum, will agree that everything is equally prudent for all users.

raccoondad

raccoondad I forgot this was about OEM unlocking...I believe its to cover any potential exploit issues.

JBirring

DeletedUser564 I think if you leave it off, your device is more likely to be flashed bootloader mode and you'll lose your data. (Im not a tech guy, just an idea).

raccoondad

JBirring your device is more likely to be flashed bootloader mode and you'll lose your data. (Im not a tech guy, just an idea).

You can do that regardless, wiping data can be done in recovery always. (This also means if you forgot your pin, no sweat! Just wipe the phone in recovery and go about your day)

GrouchyGrape

DeletedUser564 have gone thru a decade of optimization

Did you really say that developer (a.k.a. new and developing) options have gone *through a decade of optimization and therefore:

DeletedUser564 developer options are OK

That's awesome. I'd love to hear your logic. Unless I'm missing your sarcasm?

userofgos

Here's a statement from the project account in response to someone asking the following:

"Does having developer options enabled without having other settings from developer options weaken security? Is it only what settings you apply that weaken security?"

It weakens security if someone obtains the device unlocked since they can enable and authorize ADB without your PIN/password. Developer options has a PIN/password prompt. This is particularly relevant if you have other profiles which are currently in After First Unlock state.

Having developer options enabled without changing anything in it will only negatively impact things with the device unlocked. ADB being enabled will negatively impact security when it's exposed via USB so not when locked in charging-only while locked mode but it still matters.

Source: https://xcancel.com/GrapheneOS/status/1995649920162996549#m

admin

@DeletedUser564 Please avoid making unsubstantiated claims about backdoors going forward. There was absolutely no reason to derail this thread into unsubstantiated claims about backdoors as you did. It's off topic here and has absolutely nothing to do with the OEM unlocking toggle.

Contrary to your misconceptions, open hardware does not provide a way to verify there are no backdoors but rather mainly allows designing other products based on it and having the freedom to choose manufacturers for it. Open source software with reproducible builds doesn't even provide that since it's not possible to thoroughly verify large amounts of code.

DeletedUser564

admin I did no claim anything. I stated the fact, that hardware backdoors are possible and there is a large interest in them to exist.

Upstate1618

Anti theft and factory reset protection

Vincent96

Upstate1618 what?

raccoondad

Upstate1618 factory reset protection

This is not true, you can reset a device without a pin no matter what