3 ms·

Chromebooks have a different threat model; they give up once an attacker has physical access. M1s do not; their security model covers the case of preventing an

Chromebooks have a different threat model; they give up once an attacker has physical access. M1s do not; their security model covers the case of preventing an attacker from installing a backdoor on a machine using physical access. That's why Chromebooks have the screw; once you have the machine in front of you, sure, go ahead and install your own firmware. They can afford that in their threat model. We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it. Apple's security model aims for this, while still allowing the user to install their own OS.

AnthonyMouse 5y ago
> We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist. Moreover, the vulnerabilities they keep finding were there before they find them, and the ones they'll find tomorrow are there right now, if you have the resources to look. And this is distinct from the level of resources (generally considered impractical for anyone) for other forms of computer security, e.g. AES replaced 3DES in 2001 but still to my knowledge nobody -- not even the NSA or other state actors -- has ever even broken 3DES. If you ask whether a large corporation could break into an iPhone today given physical access, the answer is going to be yes. And without decapsulating your CPU. The physical vulnerabilities often end up being related to USB and things like that. Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it. > You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it. And that's really the physical access problem. If you have a device with full disk encryption and have cleared the keys from memory, the attacker might not be able to get the contents even with physical access. But if they've had physical access and then return the device to you, can you still trust it? Nope.
- marcan_42 5y ago
  > People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist. Most of which are tethered, which means they do not persist through reboots. And even if they're untethered, you can recover the platform with a DFU restore. Those jailbreaks only exist due to flaws in Apple's software, which is completely outside the premise that physical access means game over. If Apple's software were bug free there would be no practical jailbreaks, and physical access has nothing to do with it. Some of those jailbreaks work through remote access, like the ones used by NSO and company. And again, this is why they have the signing feature when installing an OS - so you can't install an older version vulnerable to a jailbreak and then give the phone to someone. > The physical vulnerabilities often end up being related to USB and things like that. Those aren't physical, they're software - checkm8 was a bug in the boot ROM. And this is why iBoot on M1 Macs doesn't support USB host mode to boot from USB disks, because the attack surface there is massive and Apple decided to find another way to allow macOS boots from USB without exposing their more critical bootloader to that. Nobody jailbreaks iPhones via physical vulnerabilities, but if they tried, Apple have been much more proactive in this area than pretty much everyone else too. They have things like memory encryption and authentication for the SEP memory area, environmental monitors, hardware design that avoids exposing things to software that could have a security impact, etc. > Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it. And every new iPhone and every bug fixed, this gets harder. The attack they used for that phone no longer applies to newer ones. It's not just a game of whack-a-mole either; Apple have been at the forefront of attack mitigations and iDevices are some of the most secure consumer devices in existence (the Xbox One might be close). Doesn't mean they get it perfect; I have an Apple security report open for a bypass for one of their mitigations. But they try harder than pretty much everyone else in the industry. > Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it. That might work to get your PIN, but if nothing else you'd immediately notice it doesn't work properly or all your data is gone. That sure beats a silent backdoor in your phone.
floatboth 5y ago
The screw hasn't been a thing for years, you prove ownership by sitting there for like 15 minutes pressing the power button when told :D But it's a lot more than just "go ahead". For stock users: enabling dev mode wipes storage and reinstalls CrOS, so trying to "attack" via dev mode a) won't give the attacker any data and b) will be extremely noticeable because the data is gone (and there will also be dev warning screens all the time unless they then make fully custom FW and CrOS that aren't secure but look exactly like stock) For custom users: you can lock the debug interface with your password! Plus do your own vboot if you're concerned about.. ehh.. flashing over SPI directly bypassing the debugger (not easy on some devices) or somehow some vulnerability allowing internal flashing from the CPU. So Chromebooks do have decent measures against physical access and allow for full CPU & EC firmware customization.
- marcan_42 5y ago
  Thanks for pointing this out. My Chromebook is from the era when they still had a screw... :-) Can you recover a modern Chromebook that has had all of its Flash memories tampered with or wiped externally, with just a USB cable? With a debug cable? That seems to be one of the major things that sets apart iDevices from others. At least this design doc still says local attacks involving e.g. replacing writable storage are out of scope (which they very much aren't for iDevices): https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery#Potential_Problems_06602847948 https://www.chromium.org/chromium-os/chromiumos-design-docs/... From block diagrams it seems Cr50 security chip in recent Chromebooks just interfaces with AP Flash and the write protect pin, and thus verified boot isn't tied to silicon tamper resistance. That puts Chromebook at around the same level as T2 Macs in terms of tamper-resistance, in fact a bit worse (on T2s the T2 chip is the flash from the AP's point of view, so you can't just tamper with an external flash memory. You could MITM it in principle, though I heard the T2 Mac boards are also designed to make this difficult to pull off with buried traces). Digging a bit more (the docs on this are really scattered...), it seems Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable, but that requires taking apart the machine, since it won't work over USB, only UART. There is no mention of any Boot ROM recovery mechanism or of how the RO firmware is authenticated; RO is supposed to be "Read Only" in on-chip Flash, but eliminating every avenue for compromise of writable Flash is very hard (e.g. glitching the Boot ROM; I've seen too many "secure" microcontrollers compromised to bypass read or write protect in various ways...), so this approach is quite a bit weaker than Apple's: on these devices, you need specialized hardware to go to the lowest level of recovery, and you can't even recover from certain kinds of volatile storage loss or compromise, while on Apple devices any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware on the machine to factory condition, and the process relies only on truly immutable mask ROM*. * I can't say for sure there isn't any auxiliary writable flash that would let you brick the machine in some other way, but I haven't found anything yet. The prime suspect, the USB-PD controller chip that's in the path of the DFU USB connection (and thus could break it if it doesn't work), smells like it boots from ROM until the OS instructs it to launch the application image from Flash. It reports being in "DFU" mode until we issue the first power state switch command to bring it up, and we know these chips are custom Apple versions with Apple ROMs and the ROM does contain most of the USB-PD stack... so this sounds like the kind of thing Apple would get TI to do, since they really care about being resistant to bricks and persistent compromise.

AnthonyMouse 5y ago

> We in security like to throw around that "once the attacker has physical access it's game over", but that isn't true in practice, as evidenced by the success of locked platforms like iPhones. People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist. Moreover, the vulnerabilities they keep finding were there before they find them, and the ones they'll find tomorrow are there right now, if you have the resources to look. And this is distinct from the level of resources (generally considered impractical for anyone) for other forms of computer security, e.g. AES replaced 3DES in 2001 but still to my knowledge nobody -- not even the NSA or other state actors -- has ever even broken 3DES. If you ask whether a large corporation could break into an iPhone today given physical access, the answer is going to be yes. And without decapsulating your CPU. The physical vulnerabilities often end up being related to USB and things like that. Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it. > You can be secure against physical access, at least assuming your attacker can't decapsulate your CPU, rewire it with a FIB workstation, and recapsulate it Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it. And that's really the physical access problem. If you have a device with full disk encryption and have cleared the keys from memory, the attacker might not be able to get the contents even with physical access. But if they've had physical access and then return the device to you, can you still trust it? Nope.

marcan_42 5y ago
> People find iPhone jailbreaks all the time. Apple patches them, but if you want a jailbroken iPhone, they exist. Most of which are tethered, which means they do not persist through reboots. And even if they're untethered, you can recover the platform with a DFU restore. Those jailbreaks only exist due to flaws in Apple's software, which is completely outside the premise that physical access means game over. If Apple's software were bug free there would be no practical jailbreaks, and physical access has nothing to do with it. Some of those jailbreaks work through remote access, like the ones used by NSO and company. And again, this is why they have the signing feature when installing an OS - so you can't install an older version vulnerable to a jailbreak and then give the phone to someone. > The physical vulnerabilities often end up being related to USB and things like that. Those aren't physical, they're software - checkm8 was a bug in the boot ROM. And this is why iBoot on M1 Macs doesn't support USB host mode to boot from USB disks, because the attack surface there is massive and Apple decided to find another way to allow macOS boots from USB without exposing their more critical bootloader to that. Nobody jailbreaks iPhones via physical vulnerabilities, but if they tried, Apple have been much more proactive in this area than pretty much everyone else too. They have things like memory encryption and authentication for the SEP memory area, environmental monitors, hardware design that avoids exposing things to software that could have a security impact, etc. > Remember the whole farce where the FBI wanted to get into some iPhone and "couldn't" because Apple refused to help them? Then they just paid somebody to break into it. And every new iPhone and every bug fixed, this gets harder. The attack they used for that phone no longer applies to newer ones. It's not just a game of whack-a-mole either; Apple have been at the forefront of attack mitigations and iDevices are some of the most secure consumer devices in existence (the Xbox One might be close). Doesn't mean they get it perfect; I have an Apple security report open for a bypass for one of their mitigations. But they try harder than pretty much everyone else in the industry. > Or steal your phone and leave you with an identical looking one that transmits your authentication to the real one as soon as you try to unlock it. That might work to get your PIN, but if nothing else you'd immediately notice it doesn't work properly or all your data is gone. That sure beats a silent backdoor in your phone.

floatboth 5y ago

The screw hasn't been a thing for years, you prove ownership by sitting there for like 15 minutes pressing the power button when told :D But it's a lot more than just "go ahead". For stock users: enabling dev mode wipes storage and reinstalls CrOS, so trying to "attack" via dev mode a) won't give the attacker any data and b) will be extremely noticeable because the data is gone (and there will also be dev warning screens all the time unless they then make fully custom FW and CrOS that aren't secure but look exactly like stock) For custom users: you can lock the debug interface with your password! Plus do your own vboot if you're concerned about.. ehh.. flashing over SPI directly bypassing the debugger (not easy on some devices) or somehow some vulnerability allowing internal flashing from the CPU. So Chromebooks do have decent measures against physical access and allow for full CPU & EC firmware customization.

marcan_42 5y ago
Thanks for pointing this out. My Chromebook is from the era when they still had a screw... :-) Can you recover a modern Chromebook that has had all of its Flash memories tampered with or wiped externally, with just a USB cable? With a debug cable? That seems to be one of the major things that sets apart iDevices from others. At least this design doc still says local attacks involving e.g. replacing writable storage are out of scope (which they very much aren't for iDevices): https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery#Potential_Problems_06602847948 https://www.chromium.org/chromium-os/chromiumos-design-docs/... From block diagrams it seems Cr50 security chip in recent Chromebooks just interfaces with AP Flash and the write protect pin, and thus verified boot isn't tied to silicon tamper resistance. That puts Chromebook at around the same level as T2 Macs in terms of tamper-resistance, in fact a bit worse (on T2s the T2 chip is the flash from the AP's point of view, so you can't just tamper with an external flash memory. You could MITM it in principle, though I heard the T2 Mac boards are also designed to make this difficult to pull off with buried traces). Digging a bit more (the docs on this are really scattered...), it seems Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable, but that requires taking apart the machine, since it won't work over USB, only UART. There is no mention of any Boot ROM recovery mechanism or of how the RO firmware is authenticated; RO is supposed to be "Read Only" in on-chip Flash, but eliminating every avenue for compromise of writable Flash is very hard (e.g. glitching the Boot ROM; I've seen too many "secure" microcontrollers compromised to bypass read or write protect in various ways...), so this approach is quite a bit weaker than Apple's: on these devices, you need specialized hardware to go to the lowest level of recovery, and you can't even recover from certain kinds of volatile storage loss or compromise, while on Apple devices any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware on the machine to factory condition, and the process relies only on truly immutable mask ROM*. * I can't say for sure there isn't any auxiliary writable flash that would let you brick the machine in some other way, but I haven't found anything yet. The prime suspect, the USB-PD controller chip that's in the path of the DFU USB connection (and thus could break it if it doesn't work), smells like it boots from ROM until the OS instructs it to launch the application image from Flash. It reports being in "DFU" mode until we issue the first power state switch command to bring it up, and we know these chips are custom Apple versions with Apple ROMs and the ROM does contain most of the USB-PD stack... so this sounds like the kind of thing Apple would get TI to do, since they really care about being resistant to bricks and persistent compromise.