1. 44

  2. 9

    This is an awesome presentation. I like how they address about every detail of the problem. Also, the pictures showing all the components and files plus mentioning an invisible, web server make this a nice, default link to send people about the subject. Tell them they can’t trust their boxes since they’re full of invisible backdoors and exploits before the OS even boots. Give them this as the proof.

    1. 2

      What do you think of using a full Linux plus custom user land vs custom firmware (the second half)?

      My non-expert read is it’s more secure than most custom firmwares, but less secure than one written using high-assurance methods (esp given the issues presented in the first half).

      1. 5

        Oh yeah, first thing I thought. My initial impression was “Decrease easy attacks on current firmwares while maintaining existing level of attacks on Linux software.” I’d rather not have Linux in the TCB. Getting Linux back in control is their focus, though. They implicitly trust it. At least they wrote a bunch of stuff in a memory-safe language.

        Honestly, I don’t know enough about the constraints and environment of Intel firmware to know what’s a good recommendation. By default, I’d rather see something like Redox or Muen here in a safe language with checks at the low-level interfaces like is done in SAFEcode/SVA-OS and House’s H Layer. What they do is wrap the low-level stuff with checks to make sure it’s used properly whether the analysis is done at compile or run-time. Then, those things are just regular functions in the rest of the safe code. Redox and Muen might already do that: haven’t read code. The x86 version of seL4 is another option for abstracting the hardware with Robaglia trying to build Rust on it and Genode building a component-based OS on it. The advantage such options will have is strong safety at a critical point in the system that you don’t want to get wrong.

        Another possibility is Oberon with lightweight runtime (esp reference counting) since even Astrobe is using it for embedded. I’m considering it in one of my investigations for secure bootstrapping since the system is described in a book in English and source code by a guy unlikely to subvert it. One can boot into a minimal Oberon that then executes commands to download, verify, or install anything else. Recode a C compiler in it for bootstrapping it if worried about Karger/Thompson attack.

    2. 6

      Ahhh nice, it actually addresses the UEFI “runtime services” (does it talk about all the ACPI horrors that Linux runs in the ACPI bytecode interpreter? Idk) as well as SMM/ME. Frankly, this level of complexity in platform firmware is terrifying, how can anyone have a hope of building a secure/trustworthy system with x86 if all this is in play?

      1. 6

        Video of this talk: https://www.youtube.com/watch?v=iffTJ1vPCSo

        I don’t understand how Intel can “get away” with this. It seems like a very odd situation when you have Google/Facebook/etc. paying Intel million/billions of dollars for CPUs for servers and Chromebooks. And then they have to do even more work to disable UEFI crap (which I guess is documented) and ME (which is not documented or disabled). He’s making it sound like a 5+ year effort to get rid of ME.

        I would think that if you are paying Intel millions/billions of dollars you would have some say in the product you get? I mean at the very least there is AMD. He mentions AMD has its own security problems, but surely you can play the vendors off each other to get the product you want.

        I could “understand” if this were smaller vendors, but these are two of Intel’s biggest customers (OCP is from Facebook as far as I understand).

        I think what I am missing is the case for UEFI and the case for ME. Who wants those things and what are they good for?

        1. 6

          I think what I am missing is the case for UEFI and the case for ME. Who wants those things and what are they good for?

          • UEFI is a modern firmware platform compared to the BIOS services; which are essentially a relic of 1981’s IBM PC, and minimally extended since. UEFI offers much nicer pre-OS services, can boot actual executables from normal file systems instead of 512-byre sector 0, (seriously IBM, should have put geometry information there instead…) and features like secure boot to ensure a chain of trust from bootloader to kernel modules. Yeah, people complain it’s not OF, but it’s a lot better than what we had before.

          • ME provides things like an on-chip IPMI-like service (enterprise WANTS this), a watchdog, and DRM services, as well as anything else the main CPU can’t perform because it’s not on.

          1. 2

            I would think that if you are paying Intel millions/billions of dollars you would have some say in the product you get?

            Oh, but capitalism does not work like that. :-)

          2. 3

            Maybe one step towards moving the market away from this would be to default to include data about the presence of UEFI, SMM, IME, PSP, etc. in the metadata of certificates and keys. Thought it’s currently almost totally impractical to avoid all of these features, this would make it possible to start putting market pressure against them. Threat models that include very resource attackers could begin distrusting the worst of these systems, with hope that it spreads. (Users of these machines could of course omit the information or lie, but but it’d be a start that’d help most with low-tech consumers who have no idea their laptop or phone includes these rootkit systems.)

            1. 2

              Disturbing and irresponsible of Intel. I wonder if the software engineers who work there know better, or really just don’t give a shit.

              1. 5

                Or are paid not to a la BULLRUN given this is a pile of remote backdoors.

              2. 2

                Nice presentation. Could someone with a deeper understanding than me comment on the role which coreboot has in this context? It works fine with me_cleaner and seems to circumvent UEFI completely if used with the right payload, but what about SMM?