Check for MSI insecure firmwares #5563
Replies: 18 comments
-
Is the IFR specification public? |
Beta Was this translation helpful? Give feedback.
-
It is part of the UEFI specification. There is a Rust implementation here: https://github.com/LongSoft/IFRExtractor-RS The part that is not standardized (but in practice every vendor uses the same) is the GUID: Foxboron/sbctl#181 (comment) |
Beta Was this translation helpful? Give feedback.
-
If I read sbctl's thread correctly, parsing IFR was necessary to discover automatically vulnerable versions of MSI firmwares. But a more generic solution on a live system might be to check the state of some PCD variables: Foxboron/sbctl#181 (comment) |
Beta Was this translation helpful? Give feedback.
-
I'm not sure how you would go about reading those PCD variables (I don't More about this here: It's probably not the best solution as it requires reading |
Beta Was this translation helpful? Give feedback.
-
/dev/mem isn't going to work with Secure Boot actually turned on unfortunately. |
Beta Was this translation helpful? Give feedback.
-
The quirk where linux distributions enable lockdown mode when secure boot is enabled is a patched behavior and absent from the vanilla kernel. Regardless of that I don't think reading /dev/mem is a good strategy. |
Beta Was this translation helpful? Give feedback.
-
I think it makes sense as a HSI check -- if nothing else because MSI doesn't actually upload firmware for their own hardware on the LVFS... |
Beta Was this translation helpful? Give feedback.
-
"Banning" MSI firmware with this bad default would leave users in an interminable state should yet another vulnerability show itself in AESA or AMD microcode which is still better dealt with at the firmware level than loading microcode after kernel boot. It's a better idea to just issue a warning to those that care about secure boot (not everyone does!) to check the relevant options in their firmware setup and get on with business otherwise. After all, MSI isn't on LVFS currently, and likely won't be in the short term future (they're actively hostile to any one mentioning anything but Windows in support tickets - I know from experience) so anyone loading MSI firmware via fwupd is doing so manually. |
Beta Was this translation helpful? Give feedback.
-
If it's between IFR or PCD, it's probably better to build a path to get PCDs. I think this will scale better. |
Beta Was this translation helpful? Give feedback.
-
@superm1 got any cunning ideas on how to get the PCDs without using /dev/mem? |
Beta Was this translation helpful? Give feedback.
-
Do it from a kernel driver that can access and parse the memory and then export the result from the kernel to userspace. |
Beta Was this translation helpful? Give feedback.
-
No need to parse PCDs because most of them are static (i.e. converted into C |
Beta Was this translation helpful? Give feedback.
-
As for detecting things like that, it'll be good to have an EFI-level agent that could try to load an unsigned binary with |
Beta Was this translation helpful? Give feedback.
-
The GUID comes from AMI, so it's not just not standardized, but AMI-specific, and the fact that downstream OEMs won't changing the GUID of their BIOS Setup (as Intel already does) can't be relied upon. However, IFR extraction can be applied to every FFS file in the image, as the tool will only generate an We already made a run of IFR extractor across LVFS once in this issue, there's a script attached there that could be used as an inspiration for a proper solution, i.e. run it every time a new image is uploaded, and check for configuration issues immediately. |
Beta Was this translation helpful? Give feedback.
-
I think the problem there is we need the client side to make noise about problems. If you're dependent upon extracting IFR, you need a way to get at it without |
Beta Was this translation helpful? Give feedback.
-
I think we need a generic way to dump the flash contents (that's not always available from |
Beta Was this translation helpful? Give feedback.
-
Agreed, but that's #4094 (comment) all over again, and it's not something easy to get in the kernel. |
Beta Was this translation helpful? Give feedback.
-
I'll move this to a discussion as it's not really something we can do yet. |
Beta Was this translation helpful? Give feedback.
-
I don't really know if this belongs to the server side or
fwupd security
HSI checks, but it would be nice to ban or warn about MSI firmwares that pretend to enable Secure Boot but actually don't: https://dawidpotocki.com/en/2023/01/13/msi-insecure-boot/It requires parsing IFR data though, which could be a lot of work on the client side if there's no library available for it. On the server side, I guess it's possible to run UEFITool in a sandbox, see the script provided at the end of the article describing the issue.
Beta Was this translation helpful? Give feedback.
All reactions