Howdy gang, in lieu of an update (for now) I’ve turned on the verbose boot mode (not near by computer, can’t remember the exact babe). This prints system info and doesn’t seem to draw the logo. Act accordingly everyone.
See my previous post here, I found it. Did not look to be in a region directly covered by bootguard if I am reading UefiTool correctly. But it might still be covered by transitively. I do not know enough to figure that out easily.
I also first found the black image and the TianoCore logo. The rest I found by doing a binary search for magic bytes of various image formats supported by the parsers that are shipped by Insyde. Frameworks Logos and the new diagnostic graphics I found in the AMD bios are mostly PNG.
Sadly no framework employee has acknowledged that this won’t parse the logo. If the logo is still parsed, the machine is still vulnerable.
Great, thank you very much!
Sadly no framework employee answers this question.
Happy new Year Alan and thank you very much for the link.
Hopefully there will be an update for the 13th Gen soon, so my Boss isnt worried about that anymore.
Have to update 40 machines then
I found the GUID 67A75EF8-C454-45A0-A648-0A2B489F9BD6 in a boot guard protected region (The framework logo with the text “framework” after it).
My interpretation is, that white regions are completely protected, yellow regions are partly protected and red regions are not protected by intel boot guard.
Where are you working?
I matched the red regions to the IBB segments listed under security and assumed from that that those should be the directly protected sections. I.e. the address of the image is not covered by any of the IBB segments.
But not like I am entirely sure on this.
You are correct, thank you very much.
I had a look at the source code. Red means protected, which is confusing to me:
Little Company in Germany, we changed to Framework Devices from our old Dell Stuff.
(40 Machines, 28 are rolled out, rest will follow if there isnt any colleague on vaction left)
Disclaimer: this post is for paranoid people only.
A machine compromised with a LogoFail attack could just pretend to do a firmware upgrade and show the new firmware version in the UI, while still being the old compromised version.
In my opinion, the only way to verify the new firmware version is using the TPM2.
Therefore you need to get a tpm2-quote and verify it (checkquote). Also to prevent attacks on the verification (e.g. spoofing a random key), you need to verify the endorsement-key signed by the TPM2-manufacturer and make sure, the attestation-key used to create the quote is stored in the TPM2 (makecredential/activatecredential).
To verify the PCR0 hash value of the TPM2, here are the firmware measurements for a Gen12 3.08 firmware:
EV_EFI_PLATFORM_FIRMWARE_BLOB
98ae98e8d8c95ad221072f6219f0d78f93e853f7839efeca553b5c5dc57ec505
EV_EFI_PLATFORM_FIRMWARE_BLOB
310c202ebc03c9af00a272e35bb04794df187345de41aebd84cba61e0ea18877
EV_EFI_PLATFORM_FIRMWARE_BLOB
1bc3bf9a394c85a6a6cfb226bbc6b1fb1e027e3d35f207f9a2192b1ba1c3ed03
EV_EFI_PLATFORM_FIRMWARE_BLOB
93ee99014cbfb2f48667329fdac9dc0638b750003b076551b7766d9f7ae80f4f
EV_EFI_PLATFORM_FIRMWARE_BLOB
60f19112d3263a2bcb3059c0c50798094fbb56b80053a94f0d3243fd6a74f9e9
EV_POST_CODE
681ac70fcab0ccad78e6d0519a50a9afb93676be893e2e6b9c06a333d6a93fb9
EV_POST_CODE
608072d8953921f15718897cbb0a47623e0c29fa7286d20beb0d733756acb643
These can be verified via the tpm2 eventlog. (e.g. on linux: tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements
)
this is amazing to hear
Heads up for anyone like me who was been semi-regularly checking this thread and LVFS for updates:
12th gen BIOS 3.08 Beta includes fix for “CVE-2023-40238 LogoFAIL”. Not great news for Linux users as this update can’t roll out via LVFS and the UEFI updater was pulled two months ago due to unexpected failures, but still…
I don’t see any similar update for the 11th gen, and I don’t know what the LogoFAIL situation is for AMD. However I still thought I’d post as I’d been assuming any progress would show up in this thread and/or in the available LVFS updates for Linux…
Realistically nobody should be using the 12th gen anymore, it’s gone nearly 2 years without a single stable patch. Kinda stinks that the early framework boards were sold as finished products; they had pretty prototype-like lifespans.
Are you talking about UEFI updates? Almost no reason to update on laptops unless there’s a security or stability issue. I have never one time updated UEFI on a laptop; to relegate a device to outmoded status because of UEFI updates not being available on an otherwise stable system seems a little silly.
Of course I’d agree that when there are no security issues UEFI updates aren’t critical. Unfortunately though, the 12th gen has had known vulns since shortly after launch: 12th Gen BIOS Vulnerability
A new firmware update for AMD should release very soon (at least as a beta) and will fix this.
Welp, turns out despite having waited too long for the first fix for this (IMO) it was incomplete. Let’s see how long Insyde takes this time…
Can we just remove images entirely? Not like they are doing anything actually useful.
Never forget that “normal users” can be frightened by text (to some it also seems cheap).
Best part is, the logos at least 12th gen shows anywhere are png. But the base BIOS seems to be a very unified build from Insyde that includes all the parsers for all formats. Number one way to be more security conscious would be to only enable / add the code for the formats actually used. It’s modular after all. The AMD FW13 also had a PXE exploit listed (with FW stating they were unsure if it could be exploited, seeing as the FW does not support PXE booting anyway. Also an issue I do not think was fixed for 12th gen yet).
That just tells you that Insyde is not being defensive in there development at all. Just throwing tons of unused code in there, when they have proven that its not secure and they seem to not even test for robustness, even after the issues were publicized.