5 ms·

> Note that at the time of writing we lack sufficient evidence to retrace how the UEFI firmware was infected in the first place. The infection itself, however,

> Note that at the time of writing we lack sufficient evidence to retrace how the UEFI firmware was infected in the first place. The infection itself, however, is assumed to have occurred remotely. And given that it's done on memory (flash, that'll persist over reboots, windows reinstall and even hdd and sdd replacement), it wasn't done by trivial scriptkids. Expect more tpm-like things "to protect you".

caaqil 5y ago
> it wasn't done by trivial scriptkids. I mean that's pretty obvious given that we're talking about APT41.
bitwize 5y ago
Things like this are why we need a verified boot chain.
- foxfluff 5y ago
  Call me old fashioned but I'd prefer to just make it impossible to write the firmware without physical access. Verification just brings it's own issues and is not a panacea. Who owns the key(s)? If not you, how do you trust them? If you, how do you write them? How do you prevent attacker from writing them? Or is it one-time programmable and your hardware becomes brick / unresellable / un-updateable if you lose your keys or don't want to pass them on to next owner? How do you make sure your keys are more secure than the machine that somehow got its firmware infected? What if the code that checks your signature turns out to have a bug? Are you stuck with it, or can you update the code? What if an attacker can infect that code..? Making this all convenient and safe is very hard and in practice either takes freedoms from you (you must trust your vendor and their signed binaries), or gives a potential attacker the same freedoms that you get. Giving you full access without enabling an attacker to have the same access is quite impractical (read: unlikely to ever happen for consumer hardware that you can order over the internet), and you still have to trust the hardware is what it claims to be when you get your hands on it. In practice, I can't audit the hardware but I'd be pretty good if I could flash it myself once it's in my hands.
  - foobiekr 5y ago
    Physical access just means that evil maid attacks go back to being interesting. You need both.
  - Moru 5y ago
    And here is was thinking we had all this solved already, a jumper on the mother board that has to be shorted to update the bios. But I'm too old to understand why that isn't good enough I guess :-)
    - eternityforest 5y ago
      I'd be annoyed if I had to open a machine. Then again, I don't think I've ever updated a BIOS in the first place. Enabling it in a machine-controlled menu that can't be navigated except by the physical keys might be better
    - iso1210 5y ago
      Can you sell your idea as a software-as-a-service platform that can rapidly expand to a $1m/month revenue stream?
    - ArnoVW 5y ago
      That works great for you and me. But the average person (or even the average IT dept) does not want to open their machine to update the BIOS. Essentially your proposition comes down to 'no BIOS updates. And that has it's own problems, from a security pov and from a manufacturing recall pov.
      - cheese_van 5y ago
        >But the average person (or even the average IT dept) does not want to open their machine to update the BIOS. I happily updated BIOS until I experienced a catastrophic failure that bricked the board, don't know how. Since then I'm terrified of updating BIOS. I've also experienced UEFI conflicts(?) loading linux to new boards that took forever to sort out. It seems BIOS development has not progressed as well or far as one might expect, but that may just be me and my klutzy bad luck.
- xvilka 5y ago
  Note though, that plain SecureBoot cannot prevent attacks like this. This is more of an area for BootGuard. The thing is, it's also not impenetrable and has its share of the flaws, same with Intel ME and similar technologies. If anything, it helps to hide the code from the watchful eye. Current security solutions are just a gimmick. It should be properly designed AND deployed in the actual hardware for that. What we currently have offers mostly protection for vendors and DRM, not the end users. It's broken by design.
  - bitwize 5y ago
    You may not like it, but the future of computing is a signed, verified chain of executables from power-on to user-level application code. That's the future we're lurching toward in fits and starts.
    - temptemptemp111 5y ago

caaqil 5y ago

> it wasn't done by trivial scriptkids. I mean that's pretty obvious given that we're talking about APT41.

bitwize 5y ago

Things like this are why we need a verified boot chain.

foxfluff 5y ago
Call me old fashioned but I'd prefer to just make it impossible to write the firmware without physical access. Verification just brings it's own issues and is not a panacea. Who owns the key(s)? If not you, how do you trust them? If you, how do you write them? How do you prevent attacker from writing them? Or is it one-time programmable and your hardware becomes brick / unresellable / un-updateable if you lose your keys or don't want to pass them on to next owner? How do you make sure your keys are more secure than the machine that somehow got its firmware infected? What if the code that checks your signature turns out to have a bug? Are you stuck with it, or can you update the code? What if an attacker can infect that code..? Making this all convenient and safe is very hard and in practice either takes freedoms from you (you must trust your vendor and their signed binaries), or gives a potential attacker the same freedoms that you get. Giving you full access without enabling an attacker to have the same access is quite impractical (read: unlikely to ever happen for consumer hardware that you can order over the internet), and you still have to trust the hardware is what it claims to be when you get your hands on it. In practice, I can't audit the hardware but I'd be pretty good if I could flash it myself once it's in my hands.
- foobiekr 5y ago
  Physical access just means that evil maid attacks go back to being interesting. You need both.
- Moru 5y ago
  And here is was thinking we had all this solved already, a jumper on the mother board that has to be shorted to update the bios. But I'm too old to understand why that isn't good enough I guess :-)
  - eternityforest 5y ago
    I'd be annoyed if I had to open a machine. Then again, I don't think I've ever updated a BIOS in the first place. Enabling it in a machine-controlled menu that can't be navigated except by the physical keys might be better
  - iso1210 5y ago
    Can you sell your idea as a software-as-a-service platform that can rapidly expand to a $1m/month revenue stream?
  - ArnoVW 5y ago
    That works great for you and me. But the average person (or even the average IT dept) does not want to open their machine to update the BIOS. Essentially your proposition comes down to 'no BIOS updates. And that has it's own problems, from a security pov and from a manufacturing recall pov.
    - cheese_van 5y ago
      >But the average person (or even the average IT dept) does not want to open their machine to update the BIOS. I happily updated BIOS until I experienced a catastrophic failure that bricked the board, don't know how. Since then I'm terrified of updating BIOS. I've also experienced UEFI conflicts(?) loading linux to new boards that took forever to sort out. It seems BIOS development has not progressed as well or far as one might expect, but that may just be me and my klutzy bad luck.
xvilka 5y ago
Note though, that plain SecureBoot cannot prevent attacks like this. This is more of an area for BootGuard. The thing is, it's also not impenetrable and has its share of the flaws, same with Intel ME and similar technologies. If anything, it helps to hide the code from the watchful eye. Current security solutions are just a gimmick. It should be properly designed AND deployed in the actual hardware for that. What we currently have offers mostly protection for vendors and DRM, not the end users. It's broken by design.
- bitwize 5y ago
  You may not like it, but the future of computing is a signed, verified chain of executables from power-on to user-level application code. That's the future we're lurching toward in fits and starts.
  - temptemptemp111 5y ago