Exploitee.rs

Basically, the generation 3 nest thermostats, unlike the older generations, use a type of secure boot called High Assurance Boot (HAB). HAB uses a chain-of-trust to verify that no part of the bootloader or firmware has been tampered with.

The OEM vendor (in this case Google) burns a cryptographic key into a one-time programmable fuse (eFUSE). The bootrom, which is the first thing to run and permanently built-in to the SoC, is in charge of verifying all subsequent secondary bootloaders, such as u-boot (which must be signed with an OEM's private key). U-boot, in turn, is tasked with verifying the Linux Kernel image's integrity before loading it. This normally creates a chain of security from processor reset down to kernel execution. It was also the reason that, until now, rooting a Nest gen 3 wasn't possible.

(Un)fortunately, there is a flaw in how the bootrom verifies images. This issue enables control of the stack, which we can leverage to gain complete unrestricted control of execution immediately before loading u-boot. Inevitably, you can use this to gain access to privileged memory and do stuff like disable kernel integrity checks.

With a custom kernel, you can do all sorts of wonderful things like enable SSH and mount the rootfs as r/w.

Right now the process is rather...involved so there's really no risk of remote exploitation. Still, this opens the door to the possibility of purchasing malware-infected Nest devices. Personally I don't think that is an issue for 99.9% of people who just buy the thing new from Google, but you never know...