Reporting Issues
Bug 3499 (CVE-2021-38576) - Empty TPM Platform Auth
Summary: Empty TPM Platform Auth
Status: RESOLVED FIXED
Alias: CVE-2021-38576
Product: Tianocore Security Issues
Classification: Unclassified
Component: Security Issue (show other bugs)
Version: Current
Hardware: All All
: Lowest major
Assignee: jiewen.yao
URL:
Keywords:
: 3510 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-07-19 11:40 UTC by Chris Fenner
Modified: 2023-10-20 06:51 UTC (History)
10 users (show)

See Also:
EDK II Code First industry standard specifications: ---
Branch URL:
Release(s) the issue is observed: EDK II Master
The OS the target platform is running: ---
Package: N/A
Release(s) the issues must be fixed: EDK II Master
Tianocore documents:


Attachments
.json file (2.02 KB, application/json)
2022-01-04 18:44 UTC, kevinj
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Fenner 2021-07-19 11:40:44 UTC
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
Comment 1 Dick Wilkins 2021-07-23 09:55:43 UTC
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.
Comment 2 Dick Wilkins 2021-07-28 11:08:43 UTC
*** Bug 3510 has been marked as a duplicate of this bug. ***
Comment 3 Stefan Berger 2021-07-28 13:24:00 UTC
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.
Comment 4 Jeremiah Cox 2021-07-28 14:34:43 UTC
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.
Comment 5 Stefan Berger 2021-07-28 15:09:59 UTC
(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'?
Comment 6 jiewen.yao 2021-08-04 14:43:34 UTC
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?
Comment 7 Dick Wilkins 2021-08-04 21:19:15 UTC
I believe this was found on platforms with AMD CPUs.
Comment 8 Stefan Berger 2021-08-05 07:37:08 UTC
(In reply to jiewen.yao from comment #6)

> 
> Would you please clarify on which platform you find this issue?

OVMF for x86 and ARM.
Comment 9 jiewen.yao 2021-08-05 08:26:49 UTC
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?
Comment 10 Stefan Berger 2021-08-05 12:29:58 UTC
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?
Comment 11 jiewen.yao 2021-09-13 12:57:47 UTC
Sample code in SecurityPkg: TcgPlatformDxe/Pei.

PR - https://github.com/tianocore/edk2/pull/1968
Git Hash: 3b69fcf5f849021aa3bc810f8100ea71c03019e5..610d8073f29f30aa2f9dd58fe9d59e0dc979d085
Comment 12 jiewen.yao 2021-09-13 12:59:57 UTC
OvmfPkg update will be in next wave.
Comment 13 John Mathews 2021-10-06 12:25:08 UTC
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".
Comment 14 Bill Keown 2021-11-01 15:28:14 UTC
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?
Comment 15 Vincent Zimmer 2021-11-02 17:21:16 UTC
Bill:

Is https://github.com/google/security-research/blob/master/pocs/bios/tpm-carte-blanche/writeup.md the issue posting you were mentioning?  

Vincent
Comment 16 Chris Fenner 2021-11-03 11:59:59 UTC
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.
Comment 17 John Mathews 2021-12-01 14:24:23 UTC
Infosec 12/1:
Kevin will get a CVE for this. Our disclosure will reference the existing platform implementation as the solution.
Comment 18 kevinj 2022-01-04 18:44:21 UTC
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
Comment 19 Gerd Hoffmann 2023-02-22 08:48:10 UTC
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?
Comment 20 Stefan Berger 2023-02-22 10:43:15 UTC
(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.
Comment 21 Gerd Hoffmann 2023-02-23 00:07:33 UTC
> I think this bug can be closed/set to RESOLVED.

Good, setting to RESOLVED/FIXED.
Comment 22 Bill Keown 2023-03-09 16:14:24 UTC
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.
Comment 23 Miki Demeter 2023-03-09 16:24:02 UTC
This is now set to public.
Comment 24 jiewen.yao 2023-10-20 06:51:32 UTC
The ovmf pr is at https://github.com/tianocore/edk2/pull/2034