Why rebooting your phone daily is your best defense against zero-click attacks | ZDNET

[jonah (Jonah Aragon)]

@ignoramous

going by the fact that the user is shown “apple logo” before shutdown

Just tested and this is not true.

[ignoramous]

Gotcha.

On iOS you can use a specific hardware key combination to force a reboot

They need to update the steps for latest iOS?

1. Press and quickly release the volume up button.

2. Press and quickly release the volume down button.

3. Press and hold the side button.

4. When the Apple logo appears, release the side button.

[SkewedZeppelin]

@ignoramous

so unlikely that all OEMs implement this alike or implement it at all.

The force reboot combo on Qualcomm and Tensor is volume up + power for 10 seconds.

[overdrawn98901]

Rebooting every day? Those are rookie numbers. I reboot every hour. Zero days are zero hours to me.

[phnx]

Amateur. 10-minute auto reboot is where it’s at.

Given the average person unlocks their phone more than 100 times per day, even a layperson can go all day without their phone rebooting a single time. 6 unlocks per hour times 16 hours is 96 unlocks needed to prevent a reboot.

[ignoramous]

@overdrawn98901

Rebooting every day? Those are rookie numbers. I reboot every hour.

@phnx

Amateur. 10-minute auto reboot is where it’s at

Y’all kid, but there’s a kernel of truth to this.

As in, the idea behind ChromeOS’ Crostini project: Boot into a new Linux instance for every app …

[jonah (Jonah Aragon)]

@ignoramous

When the Apple logo appears, release the side button.

I mean technically you can do this (keep holding until after it turns back on and shows the Apple logo), but if you let go as soon as it powers off after 10 seconds it will still reboot, so…

[Lukas (Lukas Dutovas)]

@jonah

Edit: I would note that malware specifically tailored for GrapheneOS could interfere with the automatic reboots, so watch out for that. This is another reason the feature wasn’t designed with this specific problem in mind.

This is incorrect. The auto-reboot feature of GrapheneOS is implemented on a kernel level, if anyone tried to mess with it, that would result in a kernel panic, which would cause the phone to reboot anyways.

[phnx]

GrapheneOS (@GrapheneOS)

We rewrote our auto-reboot feature in 2024 to greatly improve security by preventing bypasses through crashing the system_server process where it was implemented. It’s now in the init process where a crash causes a kernel panic + reboot. init is also tiny with few crash bugs.

[ignoramous]

@phnx

preventing bypasses through crashing the system_server process where it was implemented.

I’m afraid GrapheneOS has got this wrong.

A system server crash in midst of a reboot op would mean a soft reboot immediately (triggered by init) to bring the system server back up, post which the system server (reading the state from init) will initiate a regular reboot (code).

[jonah (Jonah Aragon)]

@Lukas

This is incorrect.

No, what I said is correct. But that does make it harder and is certainly interesting to note

Of course the entire point of GrapheneOS is hardening against sophisticated exploits, so any sort of attack is not going to be easy.

[Lukas (Lukas Dutovas)]

The developers found that it was possible to bypass auto-reboot when it was implemented in the system-server process. So they had to reiterate and implement it in the init process. I don’t understand where they’re wrong in this.

@jonah

No, what I said is correct. But that does make it harder and is certainly interesting to note

But how? If the timer runs out, the system will reboot. If the init process will be crashed to try and stop the timer, it would result in a kernel panic which will cause an immediate reboot. There is no way around this.

[ignoramous]

@Lukas

bypass auto-reboot when it was implemented in the system-server process. So they had to reiterate and implement it in the init process

Is the analysis public? I can’t say much without looking at it (and their impl).

I’m familiar with AOSP code, and to my untrained eye, it looks like reboot cannot be bypassed by merely crashing the system server process (init’s main thread also kicks off a reboot monitor thread, which force executes reboot at 300+s timeout; and persists a sysprop which instructs system server to shut itself down, if it ever comes back up in the interim)?

AOSP’s init also implements immediate reboot (hard reboot), also called “low level reboot” (for thermal events, for example), via init’s sys.powerctl sysprop.

In short, most forms of reboots (save for “cold”) are guaranteed to eventually be processed (per my reading of AOSP code) by AOSP’s init process, already.

Not sure where the definitions for “cold” reboots are. Likely some vndk/HAL/firmware, but my grok skills fail me.

[jonah (Jonah Aragon)]

@Lukas

But how?

This is not my responsibility. It is not a controversial take to say that it is possible for software to have exploitable bugs. Has this functionality been formally verified?

@Lukas

If the timer runs out, the system will reboot. If the init process will be crashed to try and stop the timer, it would result in a kernel panic which will cause an immediate reboot. There is no way around this.

This is exactly the problem with computer security. Humans over-simplify complex processes in order to understand them. There are always details that are not dealt with as a result, and some of those details can be turned into vulnerabilities.

It is simply easier to not pretend to be an expert and to not pretend that software—especially as complex as GrapheneOS—is completely infallible.

[jonah (Jonah Aragon)]

@ignoramous

it looks like reboot cannot be bypassed by merely crashing the system server process

I think you are reading this wrong because I believe GrapheneOS was talking about bypassing their auto-reboot timer, not bypassing a reboot that’s already started. I could be wrong though.