• 21 Posts
  • 1.11K Comments
Joined 1 year ago
cake
Cake day: August 4th, 2023

help-circle




  • They don’t even have to be signed…

    Yeah. My understanding is that Microsoft has signed several tools made by other companies that boot as UEFI PE executables and aren’t supposed to allow loading arbitrary (including unsigned and malicious) UEFI PE binaries, but due to security vulnerabilities in the tool, they’ll load any old UEFI PE binary you give them.

    The payload/malicious UEFI PE binaries don’t have to be signed. But the third-party tools that contain the vulnerabilities have to be signed by a signer your UEFI firmware trusts. (And the tools are signed by Microsoft, which your UEFI firmware almost definitely trusts, unless you’ve already applied a fix).

    (And I don’t know exactly what sort of tools they are. Maybe they’re like UEFI Shell software or something? Not sure. Not sure it matters that much for purposes of understanding the impact or remediation strategy for this vulnerability.)

    The fix, I’d imagine is:

    • Everyone should untrust the certificates used to sign those vulnerable tools. (And by “untrust”, I really mean they need to apply the revocations.)
    • Microsoft needs to issue new certificates to replace the ones with which they signed the vulnerable tools.
    • The companies who made those tools need to release new, fixed, not-vulnerable versions of the same tools.
    • …and get Microsoft to sign those new versions with the replacement keys.
    • And users need to migrate from the vulnerable versions to the new versions of the tools in question.

    Now, I’m not 100% sure if there needs to be yet another step in there where individual users explicitly install/trust the replacement certs. Those replacement certs are signed by Microsoft’s root certificate, right? As long as all the certificates in the chain from the root certifcate down to the signature are included with the UEFI PE binary, the firmware should be able to verify the new binary? Or maybe having chains of certs is not how UEFI PE binaries work. Not sure.

    Here is an example of something similar that disables Windows Platform Binary Table…(I’m not advocating that anybody actually use this).

    Yuck. Thanks for letting me know of that. I’m still firmly in the “learning” phase when it comes to this UEFI stuff. It’s good to be aware of this.











  • Star Trek used to be better than Star Wars.

    Main reason: weekly episodes. You had to wait years to decades for the next Star Wars. But the next Voyager was just next Wednesday, and DS9 was next Thursday. At worst, they were in reruns for the next few months at most.

    Hell. Star Trek had Star Wars beat on quantity of movies too.

    Now, it’s balanced out quite a bit and Star Wars probably has the edge right now on quantity and quality, but not by much, the gap is shrinking, and the situation could reverse pretty quickly.

    Oh, also, Roddenberry didn’t have the George Lucas syndrome making him want to retroactively ruin the whole franchise he birthed.



  • I… doubt it?

    I took the liberty of looking in the developer tools as it failed, and there was a 500 response. The connection to Hulu’s servers was all over HTTPS and I didn’t get any certificate warning, so unless my ISP managed to get Hulu’s private key or got with a corrupt registrar willing to issue a valid replacement certificate, no ISP should be able to change response codes on a man-in-the-middle basis or a redirecting-traffic-to-a-hostile-server basis.

    And given how many people have reported issues, I doubt it’s specific to any particular ISPs.

    Net neutrality being dead is a huge bummer, but I don’t think this can be blamed on that.