Hi TianoCore Community, I originally reported this issue to Microsoft, who asked me to report it to TCG, where Intel investigated, concluded it originates in EDKII source code, and asked me to report it to you. The current disclosure timeline (public disclosure 2021-09-03) is based on original disclosure to Microsoft, but if TianoCore agrees the bug is in TianoCore code, Google's standard 90-day disclosure timeline applies (https://www.google.com/about/appsecurity/) and a new coordinated public disclosure date of 2021-10-18 would apply. Summary A BIOS bug in firmware for a particular PC model leaves the Platform authorization value empty. This can be used to permanently brick the TPM in multiple ways, as well as to non-permanently DoS the system. Severity High: an attacker can exploit this bug to impersonate the BIOS to the system and permanently damage or or perform other activities that are assumed to be only possible for BIOS. Background BIOS is supposed to use Platform auth (which is initialized to NULL on each TPM reset) to authenticate itself to the TPM. It is supposed to randomize this auth value and throw it away before proceeding with the boot. How This was Discovered I observed using TPM2_PolicySecret (tool in https://github.com/chrisfenner/tippitywichit) that Platform auth is still NULL, at least when booted into Linux (and I see no reason why it should be different when booting into Windows) Code (email cfenn@google.com for access) Generic detection tool: https://github.com/chrisfenner/tippitywichit Exploit Analysis This is an escalation of privilege to BIOS-level privileges for any software which can access the TPM from the booted OS. BIOS is able to: * Create undeleteable TPM NV indices (DoS the NV space) * Access Platform hierarchy objects created by BIOS, including the PK (which is EK like in its privacy implications) * Clear the TPM * Change the EPS, breaking the EK forever * Update TPM firmware
FYI. The TCG Vulnerability Response Team (VRT) sent out an alert to the silicon vendor whose platforms were effected by this bug (VRT 0006) back in early July. This was filtered on to IFVs effected. I believe it is likely that most, if not all firmware vendors, have probably fixed the problem in their versions of the Tianocore code. I believe someone just needs to get the fix back into the main Tianocore tree.
*** Bug 3510 has been marked as a duplicate of this bug. ***
FYI: To test this using either the IBM (package tss2) or Intel TSS stack (package ) and tools on Linux, neither one of the following commands should succeed: IBM: tsshierarchychangeauth -hi p -pwdn newpass Intel: tpm2_changeauth -c platform newpass Each one has to report (upon first try!) an error message that the password cannot be changed. "... authorization failure without DA implications" would be the expected error message reported by either one of them.
A little history... I think Intel added this to their MinPlatform package in 2019: https://github.com/tianocore/edk2-platforms/commit/b4346451f925272a2af040871241d2ecdead8275#diff-285181cf62c12cc66be543d719a8e03ca4d1e655d71e24d63ac39c5c4d80485a And just a couple weeks ago we added a PCD to allow platform choice between randomize or disable of the platform hierarchy: https://github.com/tianocore/edk2-platforms/commit/bfabeef4c9a63374784bd19f18a869aa2769e011#diff-54e790c1842e2a5e0111fe8a1e1c56d8127e5aa296a127902e980213638955ce I want everyone to benefit from this, so moving to EDK2 proper sounds great, but there is a question of "when" in the boot timeline this can safely execute (and know that the "platform" no longer needs platform auth). End of End of DXE? Ready to Boot? Platform auth may be necessary to fulfill TPM Physical Presence requests, but may not be available once the UX is drawn. Perhaps we have a flag and process the request on the boot following the PPI request approval, before this code runs to close platform hierarchy. Food for thought.
(In reply to Jeremiah Cox from comment #4) > I want everyone to benefit from this, so moving to EDK2 proper sounds great, > but there is a question of "when" in the boot timeline this can safely > execute (and know that the "platform" no longer needs platform auth). End > of End of DXE? Ready to Boot? Platform auth may be necessary to fulfill > TPM Physical Presence requests, but may not be available once the UX is > drawn. Perhaps we have a flag and process the request on the boot following > the PPI request approval, before this code runs to close platform hierarchy. > Food for thought. Right... I think PPI gets treated really early and the command could be issued after it. The TCG TPM 2 menu seems to not run commands immediately but also go through PPI to issue those commands after a reboot. What comes after PPI TPM 2 command-wise? A bunch of PCR extends and that's 'it'?
In the sample platform, PlatformAuth is cleared at ReadyToLock event. (https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/MinPlatformPkg/Tcg/Tcg2PlatformDxe/Tcg2PlatformDxe.c) PPI is issued at PciEnumComplete event. (https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.c) The PlatformAuth clear is a platform behavior. Different platform may use different policy. Would you please clarify on which platform you find this issue?
I believe this was found on platforms with AMD CPUs.
(In reply to jiewen.yao from comment #6) > > Would you please clarify on which platform you find this issue? OVMF for x86 and ARM.
According to https://github.com/tianocore/edk2/blob/master/Maintainers.txt, OvmfPkg: TCG- and TPM2-related modules F: OvmfPkg/Include/IndustryStandard/QemuTpm.h F: OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/ F: OvmfPkg/PlatformPei/ClearCache.c F: OvmfPkg/Tcg/ R: Marc-André Lureau <marcandre.lureau@redhat.com> R: Stefan Berger <stefanb@linux.ibm.com> Stefan or Marc-Andre, can you provide a patch for OVMF?
jiewen.yao@intel.com I previously asked the question on the mailing list. Is the code from edk2-platforms intended to be copied over to edk2? https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib If yes, where do I copy it to? With this code being around, is this the only right approach to re-use this code or should we come up with something simpler for OVMF?
Sample code in SecurityPkg: TcgPlatformDxe/Pei. PR - https://github.com/tianocore/edk2/pull/1968 Git Hash: 3b69fcf5f849021aa3bc810f8100ea71c03019e5..610d8073f29f30aa2f9dd58fe9d59e0dc979d085
OvmfPkg update will be in next wave.
Suggestion for CVSS scoring (8.2 high): https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H For the CVE description, suggest "Platform authorization value left empty".
Question from Lenovo PSIRT team. Lenovo is tracking the vulnerabilities reported in Mantis 3515 and 3499. I was originally told these issues were to be under embargo until October 22nd. I found Microsoft and the researcher have disclosed at least one of these issues, but understand the weaknesses are rooted in Tianocore. Can you share an update on when Tianocore plans to disclose these issues, any assigned CVEs, and when the Bugzilla pages will be made public?
Bill: Is https://github.com/google/security-research/blob/master/pocs/bios/tpm-carte-blanche/writeup.md the issue posting you were mentioning? Vincent
I'm not sure where October 22nd came from as a date, our final disclosure date has been October 18th for quite some time. The other issue (#3515) was disclosed publicly on October 18th: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42299 https://github.com/google/security-research/blob/master/pocs/bios/tpm-carte-blanche/writeup.md The tools (i.e., https://github.com/google/security-research/tree/master/pocs/bios/tpm-carte-blanche/cmd/bugtool) that we released that detect that issue also detect this one. However, we don't have a writeup.
Infosec 12/1: Kevin will get a CVE for this. Our disclosure will reference the existing platform implementation as the solution.
Created attachment 909 [details] .json file .json file has been created for this bug. It has been submitted to MITRE and populated under CVE-2021-38576. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38576
What is the status here? Tcg2PlatformPei + Tcg2PlatformDxe have been added to edk2, OVMF has been updated to use them, all in 2021. Are there any outstanding TODO items or can we set this to RESOLVED?
(In reply to Gerd Hoffmann from comment #19) > What is the status here? Tcg2PlatformPei + Tcg2PlatformDxe have been added > to edk2, OVMF has been updated to use them, all in 2021. Are there any > outstanding TODO items or can we set this to RESOLVED? I think this bug can be closed/set to RESOLVED.
> I think this bug can be closed/set to RESOLVED. Good, setting to RESOLVED/FIXED.
Concern from Lenovo's PSIRT team is that to obtain the details on the vulnerability, the CVE has link to the bugzilla report which has restricted access. Per the CVE rules, if a link is used as a CVE reference, it may be behind a login prompt, but have no other restrictions. In this case, you must be part of EDK Infosec team or other authorized group to gain access. If there is another authoritative link that has details about the issue, such as a Tianocore advisory, that could also serve as a reference link.
This is now set to public.
The ovmf pr is at https://github.com/tianocore/edk2/pull/2034