4 ms·

Doesn't this open up a Blue Pill attack? https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) Linux kernel bo

Doesn't this open up a Blue Pill attack? https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) Linux kernel boots, runs MacOS in a VM, can snoop its memory, evil maid attack. This is one of the few ways that locked bootloaders benefit smartphone users (rather than benefiting only the smartphone manufacturers). This is also why ARM Chromebooks in "developer mode" display a scary message for several seconds on bootup and make a maximum-volume-level beep to get your attention. To disable that you have to replace the bootloader, which requires opening up the case (and if you're going to do that you could have just swapped the motherboard).

saurik 6y ago
Wouldn't the correct fix for this (that doesn't sacrifice freedoms of the user) to do hardware full disk encryption tied to the vendor that signed the kernel? (Effectively, the same solution as app data security used by Android.)
- KirillPanov 6y ago
  You're hand-waving past a critical detail when you say "tied to". Signing and encrypting are different processes. Verifying a signature uses the public key, which everybody has. Decryption uses a secret key, which by definition isn't publicly available. Most of the schemes you're thinking of (Intel SGX, etc) boil down to surrendering control to the CPU manufacturer and trusting them to manage your keys for you, and do the right thing. Even when pressured by nation-states.
  - saurik 6y ago
    So, I realize that many people somehow seem to think it is more correct to not look up who they are speaking with, as if that shouldn't matter; but, I find that as language is ambiguous, and often we are lazy in our speaking or assume "the other person should be able to fill in the gaps I didn't say using what I presume to be common knowledge here", it is actually somewhat important? (To said point, I tried to look up who you were to see if you were likely to somehow know more about this than I do and are just coming off as extra condescending as maybe you merely dislike me, but you don't have a bio and there are multiple Kirill Panovs ;P.) I guess I only have an indirect bio (though I do have a famous username ;P), but I will introduce myself regardless: I am Jay Freeman, aka saurik, the "godfather" (but not quite the "father") of jailbreaking. I have both developed myself and worked with others to develop many tools over the years to break various signed boot mechanisms, for both Android and, notably, iOS. I am certainly not the person I know who knows the most about how these work, and I usually do my iOS attacks further up the stack, but I certainly am not a dilettante here or anything ;P. I definitely at least understand how cryptography works :/ (and I am currently in charge of technology and architecture for a well-funded cryptocurrency project). Additionally, I happen to be a pretty intense public critic of Intel SGX (and so I have some appreciation of why people hate this kind of tech). All I am really saying here for a concrete suggested implementation for how this should work (as I take it this wasn't obvious and you are maybe "curious") is designed around an appreciation of how Apple already handles full disk encryption, so we need to examine whether your "pressured by nation states" attack already works against an iPhone (spoiler alert: it doesn't). Let's say you leave an iPhone on a table, the FBI takes it, and now Apple is required to unlock it (as in the San Bernardino case). I was a big name hitting Apple hard on this: they absolutely could bypass that phone, because they left themselves what amounted to a back door to do firmware upgrades without the user's permission (which was the actual issue at hand, not the "effort" to building a modified firmware image: anyone could have done that if Apple merely signed the result). However, this was fixed: firmware updates of both the OS and (as far as I know) the secure enclave now require the user to unlock the device. This unlock process is protected from brute force by the software running in this secure enclave, and Apple is unable to bypass it even if they are "pressured by nation states". They hadn't implemented this on the older devices, and I felt their stance in that case was thereby disingenuous, but they had already mostly fixed the issue in the subsequent already-released-at-the-time phone and they later fixed it even better. (Now, there are also was an exploit people found in those phones, but that's clearly a different problem.) What I am suggesting for this situation is to start with the iOS secure boot chain behavior but then implement a mechanism similar to the Android "wipe disk on bootloader unlock" solution that itself works similarly to the Android APK upgrade process: when a kernel is presented to the bootloader, instead of it being checked strictly for "is this signed by Apple", it would accept any kernel signed by any key... but instead of merely jumping into the kernel after loading it, it would pass the address of the memory region, the signature, and the entry point (edit: this bit needs to be inside of the signed kernel image) to the secure enclave, which would now verify the signature and jump to the entrypoint (instead of this being done directly by the secure bootloader). Since the secure enclave (which is of course immune to your blue pill attack) is now what verified the signature of the kernel, it would be able to use the hash of the public key of the certificate for the signature of the kernel as part of its key derivation path for subsequent encryption work. This would allow the full disk encryption--which is already being done in the secure enclave (keys are managed there, as you note, but without the issue you claim it has), to avoid the kernel having direct access to the root filesystem keys--to be "tied to" (which I honestly assumed anyone in this kind of discussion would understand immediately ;P) the kernel vendor (which might be the user, if they compile their own kernels: the user absolutely should be allowed to install their own kernels). (FWIW, if you want to blast me for "hand waiving" anything to the point where I imagine someone who works on this stuff wouldn't be able to quickly derive it, it is that I appreciate that kernels are usually stored on filesystems, causing a chicken-and-the-egg issue; but I personally have always found that to be incompetent, as it means that the second stage bootloader on iOS seriously has a full HFS+ filesystem parser, which has in the past been the source of bugs serious enough to cause key leakage :/. Just don't do that... somehow? Maybe do what Android does, with a separate flash partition for the kernel image? I certainly would admit that dealing with this quirk feels like a separate step.) What I like about this kind of scheme is that it makes the bootloader "work for the user" instead of merely working for Apple. It also doesn't leave the user stranded without secure boot if they want to boot their own kernel. I want a scheme where users can choose their own trust root, and that's effectively what this is automatically doing, with the secure enclave feeling more like a secure hardware piece than being relayed to the operating system. (This all said: I haven't looked at all into how the M1 works... the Apple engineers who work on this have shitty motivations and at-best-borderline morality, but they aren't stupid: if they actually got the green light to work on this, for all I know this is how it already operates. I also am only an expert on mobile systems in general, so I have never looked into the schemes developed by Microsoft and Intel... I kind of feel like, by default, they would suck, though :/.) I thereby feel like there is both a way it "should" work--which involves tying the full disk encryption to the key of the kernel vendor--which admittedly might be how it did work; but, either way: I believe that (barring mistakes in the implementation, which sadly almost certainly will exist, and may as well be "back doors" :/) it is at least possible (whether my suggestion was a complaint that Apple did it incorrectly or an accidental explanation for why they did correct) to do this without causing some kind of obvious "blue pill" attack (and yes, it does involve a secure enclave, but I believe the thing Apple does isn't as intrinsically evil as the thing Intel does, as the core problem is third-party attestation, as that is what gives you ridiculous DRM scenarios of your hardware hiding stuff from the user on behalf of the software instead of the other way around).
  - deleted 6y ago
    [deleted]
musicale 6y ago
Don't you have to explicitly disable SIP (e.g. by booting into recovery mode and disabling it there) in order to boot a custom kernel?
- bezout 6y ago
  Looks like it does: https://github.com/AsahiLinux/docs/wiki/SW%3AGetting-started https://github.com/AsahiLinux/docs/wiki/SW%3AGetting-started
Gaelan 6y ago
IIRC, you need to boot into the recovery partition and enter the admin username/password of an existing user, so I'm not sure this is doable even with physical access.
- KirillPanov 6y ago
  Just factory reset the device, as if you had bought it used (if there's no way to do this then the laptop has much, much bigger problems). Buy a new laptop, do this to it, return it the next day for a refund. Rinse, repeat. This attack is what locked bootloaders on cellphones are supposed to prevent. I don't support bootloader-locking, but it's confusing that Apple is bringing locked-bootloader smartphone-style security to their laptops+desktops and then opening up a gaping hole that they worked so hard to close on the iPhone. Seems incoherent.
  - bezout 6y ago
    You still need to enter your iCloud credentials to factory reset and unlink your account from the laptop.
Wowfunhappy 6y ago
> This is also why ARM Chromebooks in "developer mode" display a scary message for several seconds on bootup and make a maximum-volume-level beep to get your attention. I knew about the warning message, which strikes me as a reasonable security measure, but forcing a max volume sound seems incredibly irritating. What if your computer freezes in the middle of a meeting and you have to reboot?
- bsmith0 6y ago
  You can just press ctrl+D and bypass the warning without any sound. It's not a big deal at all.
  - my123 6y ago
    It is user-hostile.
    - aikinai 6y ago
      It is very clearly there to protect users. You can disagree that it’s the right trade off, but claiming it’s user hostile is incredibly disingenuous.
      - my123 6y ago
        The user who inputs his password to change security settings knows what he does. When the security system on Apple Silicon Macs was designed, having a warning on each boot when running with a relaxed policy was a red line to not cross.
- solarkraft 6y ago
  Mine doesn't (though I have heard it do it) when started by charging it, but you'll have to choose "developer options" and "boot from internal disk" to boot normally.
olliej 6y ago
to do this you have to boot into recovery mode and change the SIP settings, which requires a device password. If you have the device password you can just install malware anyway without installing a custom kernel.

saurik 6y ago

Wouldn't the correct fix for this (that doesn't sacrifice freedoms of the user) to do hardware full disk encryption tied to the vendor that signed the kernel? (Effectively, the same solution as app data security used by Android.)

KirillPanov 6y ago
You're hand-waving past a critical detail when you say "tied to". Signing and encrypting are different processes. Verifying a signature uses the public key, which everybody has. Decryption uses a secret key, which by definition isn't publicly available. Most of the schemes you're thinking of (Intel SGX, etc) boil down to surrendering control to the CPU manufacturer and trusting them to manage your keys for you, and do the right thing. Even when pressured by nation-states.
- saurik 6y ago
  So, I realize that many people somehow seem to think it is more correct to not look up who they are speaking with, as if that shouldn't matter; but, I find that as language is ambiguous, and often we are lazy in our speaking or assume "the other person should be able to fill in the gaps I didn't say using what I presume to be common knowledge here", it is actually somewhat important? (To said point, I tried to look up who you were to see if you were likely to somehow know more about this than I do and are just coming off as extra condescending as maybe you merely dislike me, but you don't have a bio and there are multiple Kirill Panovs ;P.) I guess I only have an indirect bio (though I do have a famous username ;P), but I will introduce myself regardless: I am Jay Freeman, aka saurik, the "godfather" (but not quite the "father") of jailbreaking. I have both developed myself and worked with others to develop many tools over the years to break various signed boot mechanisms, for both Android and, notably, iOS. I am certainly not the person I know who knows the most about how these work, and I usually do my iOS attacks further up the stack, but I certainly am not a dilettante here or anything ;P. I definitely at least understand how cryptography works :/ (and I am currently in charge of technology and architecture for a well-funded cryptocurrency project). Additionally, I happen to be a pretty intense public critic of Intel SGX (and so I have some appreciation of why people hate this kind of tech). All I am really saying here for a concrete suggested implementation for how this should work (as I take it this wasn't obvious and you are maybe "curious") is designed around an appreciation of how Apple already handles full disk encryption, so we need to examine whether your "pressured by nation states" attack already works against an iPhone (spoiler alert: it doesn't). Let's say you leave an iPhone on a table, the FBI takes it, and now Apple is required to unlock it (as in the San Bernardino case). I was a big name hitting Apple hard on this: they absolutely could bypass that phone, because they left themselves what amounted to a back door to do firmware upgrades without the user's permission (which was the actual issue at hand, not the "effort" to building a modified firmware image: anyone could have done that if Apple merely signed the result). However, this was fixed: firmware updates of both the OS and (as far as I know) the secure enclave now require the user to unlock the device. This unlock process is protected from brute force by the software running in this secure enclave, and Apple is unable to bypass it even if they are "pressured by nation states". They hadn't implemented this on the older devices, and I felt their stance in that case was thereby disingenuous, but they had already mostly fixed the issue in the subsequent already-released-at-the-time phone and they later fixed it even better. (Now, there are also was an exploit people found in those phones, but that's clearly a different problem.) What I am suggesting for this situation is to start with the iOS secure boot chain behavior but then implement a mechanism similar to the Android "wipe disk on bootloader unlock" solution that itself works similarly to the Android APK upgrade process: when a kernel is presented to the bootloader, instead of it being checked strictly for "is this signed by Apple", it would accept any kernel signed by any key... but instead of merely jumping into the kernel after loading it, it would pass the address of the memory region, the signature, and the entry point (edit: this bit needs to be inside of the signed kernel image) to the secure enclave, which would now verify the signature and jump to the entrypoint (instead of this being done directly by the secure bootloader). Since the secure enclave (which is of course immune to your blue pill attack) is now what verified the signature of the kernel, it would be able to use the hash of the public key of the certificate for the signature of the kernel as part of its key derivation path for subsequent encryption work. This would allow the full disk encryption--which is already being done in the secure enclave (keys are managed there, as you note, but without the issue you claim it has), to avoid the kernel having direct access to the root filesystem keys--to be "tied to" (which I honestly assumed anyone in this kind of discussion would understand immediately ;P) the kernel vendor (which might be the user, if they compile their own kernels: the user absolutely should be allowed to install their own kernels). (FWIW, if you want to blast me for "hand waiving" anything to the point where I imagine someone who works on this stuff wouldn't be able to quickly derive it, it is that I appreciate that kernels are usually stored on filesystems, causing a chicken-and-the-egg issue; but I personally have always found that to be incompetent, as it means that the second stage bootloader on iOS seriously has a full HFS+ filesystem parser, which has in the past been the source of bugs serious enough to cause key leakage :/. Just don't do that... somehow? Maybe do what Android does, with a separate flash partition for the kernel image? I certainly would admit that dealing with this quirk feels like a separate step.) What I like about this kind of scheme is that it makes the bootloader "work for the user" instead of merely working for Apple. It also doesn't leave the user stranded without secure boot if they want to boot their own kernel. I want a scheme where users can choose their own trust root, and that's effectively what this is automatically doing, with the secure enclave feeling more like a secure hardware piece than being relayed to the operating system. (This all said: I haven't looked at all into how the M1 works... the Apple engineers who work on this have shitty motivations and at-best-borderline morality, but they aren't stupid: if they actually got the green light to work on this, for all I know this is how it already operates. I also am only an expert on mobile systems in general, so I have never looked into the schemes developed by Microsoft and Intel... I kind of feel like, by default, they would suck, though :/.) I thereby feel like there is both a way it "should" work--which involves tying the full disk encryption to the key of the kernel vendor--which admittedly might be how it did work; but, either way: I believe that (barring mistakes in the implementation, which sadly almost certainly will exist, and may as well be "back doors" :/) it is at least possible (whether my suggestion was a complaint that Apple did it incorrectly or an accidental explanation for why they did correct) to do this without causing some kind of obvious "blue pill" attack (and yes, it does involve a secure enclave, but I believe the thing Apple does isn't as intrinsically evil as the thing Intel does, as the core problem is third-party attestation, as that is what gives you ridiculous DRM scenarios of your hardware hiding stuff from the user on behalf of the software instead of the other way around).
- deleted 6y ago
  [deleted]

musicale 6y ago

Don't you have to explicitly disable SIP (e.g. by booting into recovery mode and disabling it there) in order to boot a custom kernel?

bezout 6y ago
Looks like it does: https://github.com/AsahiLinux/docs/wiki/SW%3AGetting-started https://github.com/AsahiLinux/docs/wiki/SW%3AGetting-started

Gaelan 6y ago

IIRC, you need to boot into the recovery partition and enter the admin username/password of an existing user, so I'm not sure this is doable even with physical access.

KirillPanov 6y ago
Just factory reset the device, as if you had bought it used (if there's no way to do this then the laptop has much, much bigger problems). Buy a new laptop, do this to it, return it the next day for a refund. Rinse, repeat. This attack is what locked bootloaders on cellphones are supposed to prevent. I don't support bootloader-locking, but it's confusing that Apple is bringing locked-bootloader smartphone-style security to their laptops+desktops and then opening up a gaping hole that they worked so hard to close on the iPhone. Seems incoherent.
- bezout 6y ago
  You still need to enter your iCloud credentials to factory reset and unlink your account from the laptop.

Wowfunhappy 6y ago

> This is also why ARM Chromebooks in "developer mode" display a scary message for several seconds on bootup and make a maximum-volume-level beep to get your attention. I knew about the warning message, which strikes me as a reasonable security measure, but forcing a max volume sound seems incredibly irritating. What if your computer freezes in the middle of a meeting and you have to reboot?

bsmith0 6y ago
You can just press ctrl+D and bypass the warning without any sound. It's not a big deal at all.
- my123 6y ago
  It is user-hostile.
  - aikinai 6y ago
    It is very clearly there to protect users. You can disagree that it’s the right trade off, but claiming it’s user hostile is incredibly disingenuous.
    - my123 6y ago
      The user who inputs his password to change security settings knows what he does. When the security system on Apple Silicon Macs was designed, having a warning on each boot when running with a relaxed policy was a red line to not cross.
solarkraft 6y ago
Mine doesn't (though I have heard it do it) when started by charging it, but you'll have to choose "developer options" and "boot from internal disk" to boot normally.

olliej 6y ago

to do this you have to boot into recovery mode and change the SIP settings, which requires a device password. If you have the device password you can just install malware anyway without installing a custom kernel.