From what I've seen it's mostly firmware for older equipment that may no longer be available on he manufacturers' website, or firmware that was only made available to OEM's or enterprises. You often find this on obscure forums.
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.
That’s not how it works. Open source software has vulnerabilities all the time.
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.
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.
This isn’t security by obscurity and that’s not how vulnerabilities work.
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.
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.
You are replying to a small part of one sentence? In context I am clearly not saying what you suggest.
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.
One can assign eyes to critical components in open source. I think you’re equating non-open Source software with commercial software. There are many commercial open source projects.
I recently updated the firmware on an MSI motherboard and since then machine suffers from occasional memory errors. Could be just by coincidence, but the timing was very close. Zero problems for months (probably years), first problem 4 hours after the upgrade. Downgraded later to the previous firmware version, but that did not change anything anymore.
Could be that the upgrade reset timing/other parameters, or attempted to optimise or overclock them, so they are no longer well suited for the ram you have installed, and that the downgrade did not reset then back to what they were previously.
That's actually true. DMI previously claimed "Configured Memory Speed: 3200 MT/s" and after the first upgrade "Configured Memory Speed: 2133 MT/s". That did not return after BIOS downgrade.
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.
> 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.
Looking into https://en.m.wikipedia.org/wiki/Serial_presence_detect a bit more after the BIOS upgrade the memory is clearly configured at SPD speeds. Maybe A-XMP was previously enabled by the first user (an employee who quit) or the factory. At least on DMI level it looks like that. Why SPD would work less reliably is strange, but as you say complicated stuff is complicated... Enabled A-XMP now and waiting for the next crash (hopefully in vain).
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.
If the system loaded the wrong profile, it may also be undervolting the memory or running tight timings. I recommend manually setting the correct memory settings. What you're describing is something I've seen happen often and I fixed it that way.
From my private conversations with MSI 2 months ago:
> 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.
I dont think anything has changed. I have a z790 msi board in front of me and I can still write to the spi flash with linux's builtin mtd driver. Even if secure boot and kernel integrity is enabled, the 2nd mtd device (which is the one with the firmware) remains writable...
Not that I'm complaining. I think its a good thing.
I am aware that the SPI is unlocked, but MSI claimed that this is somehow supposed to protect against flashing unauthorised firmware, even with SPI unlocked. I don't really trust them though.
I don't know of any modded firmware for Z790 yet. I did change some of the settings storage and it continued booting fine. If it'll refuse to boot when I change certain areas, I don't know. I would not like to discover it, though.
If the attackers leak the dataset, isn't this good for technology and community as a whole? A part of me wants this to happen, and a part realise these are NDA'd data that can get sby publisher or downstream custom rom developer in a hot jam.
Isn’t it the exact opposite though? When it was all proprietary, and someone posted a bin file claiming it was official, you could somewhat reliably expect it was since no one else could have built it.
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.
No it's been trivial to make cracked unsigned binaries via disassembly for a long time. Only a 1 bit change is often needed to disable something important. It's unclear that anyone making malicious binaries with their keys will bother to setup a proper compilation environment.
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.
Not really, no. Anybody can take an existing bin file, open up a hex editor, and modify it. Append another function to the assembled binary (or overwrite a rarely used portion of the file), change the destination of a JMP instruction, and you’re now executing attacker-inserted code.
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).
The firmwares are almost universally cryptographically signed on modern motherboards, and I'm guessing the warning comes from the signing keys being hacked.
It's The Register's schtick. I don't get the appeal either, but they've been writing like this for decades. It's like they got their writing inspiration from 90s gaming magazines and never looked back
Yeah they could, the article mentions this. The article fails to mention that one of the major motherboard manufacturers recently had their “auto update” software compromised and it was pushing malicious updates over the air. I forgot if that was also MSI or some other company.
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.
Yes, but most of their boards don't have the most basic protections (like all of the DIY mobo industry), because their customers don't care at all.
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.
56 comments
[ 3.0 ms ] story [ 132 ms ] threadI'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.
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.
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.
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
2: https://docs.dasharo.com/variants/msi_z690/overview/
Not that I'm complaining. I think its a good thing.
Are you flashing official firmware or modded?
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).
Now yes, journalists gonna journalism, but this is just bad writing. I would expect this kind of writing in casual conversation, not a publication.
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.
1: https://twitter.com/pinkflawd/status/890334031593721856
2: https://news.ycombinator.com/item?id=34388533
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.