The rest of the article is just ranting that if you enable the option in the BIOS to install Gigabyte's software it will end up being installed.
The issue here is not motherboard can execute arbitrary code. Motherboards are trusted hardware. You pass all your keystrokes, network traffic and memory transfers over it.
The issue is motherboard uses its trusted status to run software that performs raw HTTP downloads for firmware. Which is probably bad but might alternatively just be futureproofing to avoid having to deal with expiring certs.
FTP is still advertised for download of this OS, but any tampering or otherwise corrupted files will not pass a signature test when signify is invoked.
The keys are rotated for every release, the next expected key is always included in the current OpenBSD release.
This system would be safe to fetch sensitive content over cleartext http.
EDIT: Here is a paper on signify:
Date: Wed, 31 May 2023 14:13:10 UTC
Valid-Until: Wed, 07 Jun 2023 14:13:10 UTC
Of course, you still have to get current time somehow but I guess once RTC is set the device can assume the changes in time won't be huge and just use any kind of https source for that.
It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.
https://security.googleblog.com/2015/12/an-update-on-sha-1-c...
Even OCSP was affected: https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1...
Public CAs are not very secure as NSA proved and I am not sure why there is no better alternative yet.
Or, the cert could have been issued by an authority which issued the cert despite compliance problems.
Web PKI is different than code signing, but if you look at the discussions within the CAB forum, there are very good reasons to limit certificate lifetime.
So the HTTP request leaks information about the update and could be MITM, but the result could at best be an older version? (Which could be a known exploitable one!)
Which is why it might be more future proof to embed your own non expiring cert and use an out-of-band signature verification for firmware rather than relying on being able to establish an HTTPS connection forever.
No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.
If you have working signature infrastructure you don't need encryption. There is some danger, attacker can see what you are getting, but that's far lower than "the update broke"
They notably aren't saying that the firmware or loader is doing no validation on the executable. Most likely this has some sort of home grown signature on the blob, because if it didn't they instantly would have cooked up a MitM exploit to demonstrate. The fact that they didn't implies that it doesn't work.
That's not to say this is a good design (it's clearly not) or that it can't be abused in non-malware ways (junkware, etc...). But it does seem like it's being spun as a clear security hole when my guess is that it isn't (it certainly hasn't been shown to be).
No, the firmware copies a program from itself to Windows, that program then downloads and executes another program from the internet, without verifying it correctly.
Article says: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." So unless that is downright wrong the MitM path is wide open. There is a signature check built into Windows, but way too much stuff has been signed to make that a meaningful barrier.
"The firmware does not implement any cryptographic digital signature verification or any other validation over the executables."
Unless your Windows was configured to only run signed software or Gigabyte would apply the Mark of the Web to these files (which would make it harder for them to run their own update process), the executable file downloaded and run as a service doesn't seem to get checked.
As far as I can make out from the blog post, a MitM attack during the motherboard update process would allow for the motherboard to be flashed with malicious software which in turn would indeed allow for dropping Windows executables onto the system. Luckily, barely anyone uses the built-in online updater for their motherboards.
The https://software-nas/Swhttp/LiveUpdate4 URL is a pretty potential risk. You don't even need MitM to pretend to be that URL as it's not a FQDN. If there's any kind of HTTPS certificate validation that URL seems pretty useless in general. Maybe it's some kind of internal testing server that made it into production?
Now, that junk is preloaded onto the motherboard? Argh.
At least I can still opt not to install it, but jeez.
> The rest of the article is just ranting
I am puzzled by your conclusion.
Edit:
> enable the option in the BIOS to install Gigabyte's software it will end up being installed
Am i blind? Zero snark intended but where in the article is that mentioned?
So the next question probably should be, are we sure there is no other signing mechanism at play here? If the blob downloaded needs to pass some sort of signature verification to be loaded, the use/lack of HTTPs wouldn't be a big factor in the security model.