MSI confirms cyberattack, warns against unofficial firmware
theregister.com
theregister.com
Obviously you shouldn’t have trusted that, but with the code all available now, you should not at all trust any binaries which you can’t directly tie to MSI.
With similar systems that intentionally support open source one can just switch to trusting some hobbyists keys instead of the compromised vendor. There's very little incentive for vendors to set that up correctly though.
Proprietary source code doesn’t provide any assurance of authenticity of the binary. For that, you need either cryptographic signatures (binary is vouchsafed by entity X), open source builds (binary behavior matches human-readable behavior in source), or ideally both (source is vouchsafed by entity X, binary behavior matches behavior of source).
Please release this so that I can have Coreboot.
> Our MB products offer M-FLASH feature, and our Intel 700 BIOS ROM files support Secure Flash so they cannot be modified or altered by tools.
> With Secure Flash support the BIOS ROM files are safer from malicious attempts.
My understanding is that they started signing their firmware with 700-series Intel boards (idk about AMD) in some way. The "Secure Flash" they are talking about seems to be something from AMI which is an implementation of NIST SP 800-147[1].
> Please release this so that I can have Coreboot.
Code is not necessary to add their boards to coreboot. E.g. MSI PRO Z690-A has coreboot support[2]. Also, looking at that code would cause legal issues for the project.
1: https://csrc.nist.gov/publications/detail/sp/800-147/final
Not that I'm complaining. I think its a good thing.
Are you flashing official firmware or modded?
Now yes, journalists gonna journalism, but this is just bad writing. I would expect this kind of writing in casual conversation, not a publication.
The code being open just makes detection easier, or so the theory goes. It’s actually an open question.
Linus’ law only applies to the number of eyes relative to lines of code. In a world where one unappreciated person in Nebraska owns a critical part of an open codebase, including dependencies, closed software may be more secure by nature of owning the supply chain and assigning eyes to the critical components.
In theory, in practice it's not better, if not worse.
Is the portion of that sentence you didn’t quote. It changes the meaning significantly.
Either it is secure by design and nothing security critical can be learned from looking at the source code, or any vulnerabilities will only be known and available to groups willing to decompile it - which, btw, is usually only the bad actors.
There's no such thing as "secure by design" unless you make pies by first inventing the universe. Last time I checked all our hardware is proprietary. I certainly don't write all my compilers personally. The "design" of open software is that we accept what others have done, and the value comes from our inability to audit all of it. If we could, it wouldn't need to be open. We could just write it all ourselves, perfectly. In theory.
Linus’ law assumes someone actually looks. With closed software people are paid to look. With free (as in beer) software nobody is incentivized to look. In this way the openness of software doesn’t incentivize security, even if it is morally superior.
>closed software may be more secure by nature of
There is simply no security benefit offered by requiring access and knowledge of decompilers and reverse engineering to see the source code and recompile the software, and numerous security disadvantages.
The very next words are “assigning eyes to the critical components”.
The benefit of closed software in this context is that someone is paid to look. That’s not unique to closed software but having someone look isn’t guaranteed with open software either.
Or they are paid to look the other way. Or it’s just not in the budget this year.
> With free (as in beer) software nobody is incentivized to look.
Only in the sense that there is no external incentive to look. Users of the open source library, however, have an intrinsic incentive not to open themselves up to vulnerability. For example, companies paying for audits for libraries they use, where the audit is cheaper than reproducing the library in total.
Making code doesn’t change that incentive. It just prevents people from acting according to it.
But the comment I replied to is literally:
> It wouldn't happen if all it was open source to begin with.
Which is untrue, given the existence of open source vulnerabilities.
In case you forgot/not heard, MSI also broke Secure Boot on purpose and didn't mention it anywhere[2].
And let me pull up another quote from MSI:
> We've started to lock ME FW on our MBs since Intel 700 series.
Yup, Intel ME was in manufacturing mode until new boards released in Q4 of 2022 on MSI boards. Why? Got no answer from them, unsurprisingly.
All of the manufacturers seem to use godawful driver software and it feels safer just leaving them uninstalled and adjusting settings in the BIOS, if needed.
For example, on MSI PRO Z690-A, you are able to install coreboot to replace the official proprietary firmware from the OS, because the firmware regions are left writable.
They have some signing in 700-series Intel boards like I have mentioned in another comment, but I can't tell how it actually works.
I'd guess the security issue from such firmware would be someone offering L33t Ultra Kustom[1] firmware based on the leaked code that claims to do something people want (remove overclocking limits on lower end boards or whatever) but also slips in something like a SMM rootkit or whatever alongside it. Although it would be a rather narrow target profile, so I suspect it’s somewhat theoretical.
MSI also has a bit of a support / PR issue if the L33t Ultra Kustom firmware didn't have a rootkit, but managed to somehow brick the hardware because some software / firmware restrictions are there for a reason.
[1] You can tell, I'm really down with the kids.
Otherwise it probably is coincidence.
I was first concerned that my builds might have gotten slower. But it was certainly no drastic if at all. So I forgot about the whole thing because the (lack of) reliability has become a much bigger concern.
I have never practiced any overclocking. But how a system running significantly slower could be less stable exceeds my imagination.
Anything timing related can be quite finicky. Often it isn't the absolute speeds that is an issue but how that interacts with the signalling frequencies of everything else (CPU cores & cache timings, any other bus or participants on it, …) and you might get stable results by tweaking those. Also latency settings could be affected similarly. And the voltage range in which RAM and other components are stable at will vary on workload and signalling frequency.
You may even find that your RAM doesn't officially support that speed and so its batches are never tested with those settings (or are and have been found to be less stable): the setup your upgrade changed to could be off-spec via under-clocking.
That is why I tend to stay away from over-clocking: if you are not lucky enough to hit a sweet spot first time you can spend a great many hours trying to find a combination of factors that both gets gains and remains stable.
Sorry, for the digression. I doubt I have a compromised BIOS, at least I download it from their support and not from any shady source. But the topic made me looking in this problem again, and maybe understand more.