Can downgrade with same patch level?

Watermelon

Out of curiosity, does the recovery's OTA sideload feature accept older GrapheneOS builds with the same underlying security patch level? I get that the verified boot rollback protection is based on the patch level, but I'm not sure if the OTA sideload uses that or the build number. (I won't test such a thing on my personal device, and I have no need to, thankfully 😊)

And if I'm at that already: Does it accept the stock OS OTA packages? (The device with the GrapheneOS verified boot key installed still trusts the hardwired stock key.)

Thanks

Ammako

Watermelon And if I'm at that already: Does it accept the stock OS OTA packages? (The device with the GrapheneOS verified boot key installed still trusts the hardwired stock key.)

You can't flash an update with a different signature than the currently installed OS without unlocking the bootloader first, and once the bootloader is unlocked, verified boot keys stop mattering (the OS you are installing does need to properly support verified boot before you re-lock, however.)

A key being trusted only means that it can be used for verified boot with a locked bootloader, but verified boot ensures that they key needs to match with what is currently installed before it will allow updates to install. It doesn't accept overwriting the OS with a different one just because both keys are used. It's a security feature, otherwise it would be trivial to exploit GrapheneOS by reflashing the stock OS before trying to extract user data. Verified boot protects against this by enforcing that user data must be erased when unlocking the bootloader, as well.

raccoondad

Watermelon does the recovery's OTA sideload feature accept older GrapheneOS builds with the same underlying security patch level?

No, they are signed with a timestamp, the timestamp of a new update must be => of the timestamp of the OS update on the device.

Ammako

Ammako It doesn't accept overwriting the OS with a different one just because both keys are used.

used --> trusted... I was seconds away from being able to edit and correct that mistake.

Also I might as well clarify that stock OS on supported devices is relatively resilient against before-first-unlock exploits as well, which you would need if verified boot allowed overwriting custom OS with stock without unlocking (since you need to power down to enter recovery and sideload an update), so it wouldn't exactly be trivial. but stock does lack a lot of protections GrapheneOS has, which could make certain exploits possible where they wouldn't work against Graphene. and by "exploit GrapheneOS" here I meant "extract user data from a GrapheneOS phone", since in this hypotetical scenario, GrapheneOS wouldn't actually be directly exploited. Just for the sake of being pedantic about it.

Watermelon

Ammako Ammako Hey, thanks for replying. I'm not concerned with how the recovery is implemented in other operating systems or AOSP, as I don't use them, I use GrapheneOS 😊 I just wanted to know whether the GrapheneOS recovery accepts any OTA package that's trusted by the hardware, or only GrapheneOS versions that identical to the installed version or newer.

It's an interesting question because on one hand I can imagine that it could be useful to downgrade GrapheneOS if the latest version has some severe issue, but on the other hand it could be nice to be assured that downgrades of any kind are prevented by the GrapheneOS recovery as an extra measure on top of verified boot, which gives some assurance against mistakes when sideloading OTA updates.

Ammako A key being trusted only means that it can be used for verified boot with a locked bootloader, but verified boot ensures that they key needs to match with what is currently installed before it will allow updates to install. It doesn't accept overwriting the OS with a different one just because both keys are used. It's a security feature, otherwise it would be trivial to exploit GrapheneOS by reflashing the stock OS before trying to extract user data. Verified boot protects against this by enforcing that user data must be erased when unlocking the bootloader, as well.

A few months ago I asked here on the forum if the verified boot feature accounts to the scenario of an attacker managing to rewrite the system partitions of an outdated GrapheneOS installation with the authentic system partitions of an up-to-date stock OS installation, since both of their verified boot keys are trusted at the same time. The official GrapheneOS project account gave me a definitive answer that one of the inputs for deriving the keys used for disk encryption (for both Credential Encrypted (CE) and Device Encrypted (DE)) is the single verified boot key of the actively booted OS and not the whole trusted set of verified boot keys, in addition to green/yellow verified boot state and other OS-specific details. You mentioned flashing (which requires an unlocked bootloader) which isn't exactly what I meant, but assuming for a second that the GrapheneOS recovery allows sideloading the stock OS to downgrade from GrapheneOS to the stock OS without your data being erased, fortunately verified boot would make sure that your data stays inaccessible to the unhardened stock OS. (The moderators hid this discussion so you can't see it anymore, I'm not entirely sure why they did but oh well.)

Anyway, the only reason I'm asking all of it is just being curious what kinds of OTA packages the GrapheneOS recovery accepts.

de0u

Watermelon I just wanted to know whether the GrapheneOS recovery accepts any OTA package that's trusted by the hardware, or only GrapheneOS versions that identical to the installed version or newer.

https://grapheneos.org/usage#updates-sideloading

Watermelon

de0u This is relevant but doesn't answer the question. Specifically, it says: "This includes providing downgrade protection, which prevents attempting to downgrade the version. If recovery didn't enforce these things, they would still be enforced via verified boot including downgrade protection".

It says the recovery protects from downgrades, which is true but doesn't specify how.
It says it prevents downgrading the version but doesn't specify if it only prevents downgrades to versions with a lower security patch level or lower build number.
And it says that verified boot itself enforces the same things as the recovery enforces, but I know that verified boot enforces downgrade protection based on the security patch level and not the build number, which implies that it would accept any OTA package of GrapheneOS so long as it's properly signed and has at least an equal patch level as currently installed.

raccoondad No, they are signed with a timestamp, the timestamp of a new update must be => of the timestamp of the OS update on the device.

May I ask how you know?

raccoondad

Watermelon May I ask how you know?

Attempt to flash a lower build #

de0u

Watermelon I am 100% not an expert on this, so maybe an expert will chime in, but here's what I think I see.

In bootable/recovery/install/install.cpp, InstallResult() checks ViolatesSPLDowngrade() from install/spl_check.cpp, which appears to consult ro.build.version.security_patch, which in my build trees appears to be a security patch level of the sort that turns up in the GrapheneOS changelog (it is not the date that the build occurred).
But also in install/install.cpp CheckPackageMetadata() calls CheckAbSpecificMetadata(), which consults ro.build.date.utc, which I think is an actual build timestamp, though maybe it isn't for the emulator, and before I could figure out exactly how that property gets set I'm afraid I got lost in the build system.
Other things are checked too... ro.build.fingerprint of the current system is checked against the "package pre-build fingerprint" if there is one.

So I think a security patch level is checked and I think a build timestamp is checked. And other things may be checked depending on the package contents.

Watermelon

raccoondad Attempt to flash a lower build #

I don't want to sound obnoxious but sometimes it's necessary to ask simple questions like "have you tried turning it off and on again". So may I ask which build you had installed and which you were trying to sideload, if you remember?

de0u Thank you for the info

Watermelon

de0u I checked the file you mentioned. I found a spelling mistake in the source code:
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L73
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L163
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L223

I found this comment in the same file:
https://github.com/GrapheneOS/platform_bootable_recovery/blob/18fdc643bf3bb9221bb975acd1ab1144e27e5b31/install/install.cpp#L147-L149
From what I could understand (I'm likely wrong somehow) from skimming over this file, there's four things:

Security patch level: never allowed to be downgraded — enforced by the recovery sideloading and by verified boot.
Build ID: never allowed to be downgraded — enforced by the recovery sideloading.
"Incremental" version: allowed by the recovery sideloading to be downgraded only if the OTA update package is explicitly marked as a "downgrade" package.
Build date/timestamp: allowed by the recovery sideloading to be downgraded only if the OTA update package is explicitly marked as a "downgrade" package.

It seems that the security patch level is the most coarse-grained version, the build ID is more fine-grained, and the "incremental" version number is the most fine-grained version number. It seems that the GrapheneOS team puts their build numbers as both the build ID and the "incremental" version number, identically.

de0u

Watermelon So may I ask which build you had installed and which you were trying to sideload, if you remember?

Have you been able to downgrade via sideloading an old build? If so, which build were you running and which were you able to sideload?

Watermelon

de0u Have you been able to downgrade via sideloading an old build? If so, which build were you running and which were you able to sideload?

I haven't tested it, and I don't have a second device to test it on, sadly.

de0u

Watermelon I haven't tested it, and I don't have a second device to test it on, sadly.

That's understandable.

At this point I believe we have some reason to believe that the code in Recovery checks both a build timestamp and a security patch level, and we have a report (admittedly not super-detailed) that a user got an error about a build timestamp.

From the code, I expect the error would be "Update package is older than the current build, expected a build newer than timestamp NNNNN but package has timestamp MMMMM and downgrade not allowed", which would be straightforward to interpret. The error message for a security patch level discrepancy is quite different.

Watermelon

de0u expected a build newer than timestamp NNNNN

Should be said, I've seen the GrapheneOS project recommending users with boot failures to try to sideload the current OS version in the recovery in order to reinstall the OS, so it seems like it accepts at least the current build rather than only newer builds.

de0u

Watermelon I've seen the GrapheneOS project recommending users with boot failures to try to sideload the current OS version in the recovery in order to reinstall the OS, so it seems like it accepts at least the current build rather than only newer builds.

I quoted the message from the code, not the code itself. The message might be off-by-one in the way you suggest. I'm not going to have time for at least a couple of days to go back and look at the code again, but since the file names and function names are available it would be easy for interested parties to check.

de0u

Watermelon I checked the file you mentioned. I found a spelling mistake in the source code [...]

LOL, and it appears some IDE happily amplified the mistake.