6 ms·

HTTPS is irrelevant here. You can send incorrect headers in either.

• 1970-01-01 3y ago
  MITM scenarios say it isn't :P
  • 38 3y ago
    you cant MITM HTTPS unless you're are doing it to yourself for testing.
    • hiddencost 3y ago
      Secure boot.
    • 8organicbits 3y ago
      Are you sure? It's pretty common for small tools like this to skip HTTPS certificate verification because of space constraints (typical CA trust root collections are around 100 KB in size). Since this is doing certificate verification of the downloaded file, HTTPS verification is usually redundant. If the HTTPS certificate verification is skipped then MITM of the HTTPS connection is trivial. I took a quick look at the code and I'm not seeing the usual steps for certificate management, although I may have missed it.
      • cesarb 3y ago
        > because of space constraints (typical CA trust root collections are around 100 KB in size). Since shim is an executable in the ESP, which is a HDD or SSD partition, the space constraints are more relaxed (it's not a small SPI NAND chip).
• tsimionescu 3y ago
  The flaw here is only exploitable by (1) a malicious server, which could anyway just send a malicious binary, no need for header shenanigans, or (2) a MITM. Case 1 is moot, case 2 would be prevented by properly implemented HTTPS. On the other hand, I don't think it's practical to actually implement HTTPS properly in UEFI, since you'd have to constantly update the trust store, and you'd have to have actual internet access to be be able to check the certificate revocation lists (otherwise, you are vulnerable to surreptitious malicious activity from otherwise trusted CAs).
  • oconnore 3y ago
    > Case 1 is moot, case 2 would be prevented by properly implemented HTTPS. That's not true. It's significantly easier to ensure the security of an offline signing key than it is to ensure that an arbitrary HTTPS server avoids ever becoming compromised.