Merge pull request #145 from ericchiang/event-log-disclosure

docs: add TCG disclosure report

docs/event-log-disclosure.md

@@ -0,0 +1,135 @@
+# Verifying TPM Boot Events and Untrusted Metadata
+
+This is a disclosure of a vulnerability report sent to the Trusted Computing Group.
+
+## TPM boot logs
+
+TPMs are cryptographic hardware that, among other things, can be used to verify the boot state of a machine; that a machine booted a specific OS, enabled specific BIOS settings, and hasn’t had its bootchain tampered with.
+
+As a machine boots it records events, such as the bootloader hash and secure boot keys, in a structure called the Event Log.  When an event is written to the log, its digest is also written to rolling hashes in the TPM called PCRs. PCR values can be attested remotely by the TPM and used to verify the log by replaying the log’s digests. If the replay matches the PCRs’ values the log hasn’t been tampered with.
+
+An Event Log is a series of events using the following format (the TPM 2.0 format is slightly different but functionally the same):
+
+```
+typedef struct tdTCG_PCR_EVENT {
+    TCG_PCRINDEX  PCRIndex;         // PCRIndex event extended to
+    TCG_EVENTTYPE EventType;        // Type of event (see EFI specs)
+    TCG_DIGEST    Digest;           // Value extended into PCRIndex
+    UINT32        EventSize;        // Size of the event data
+    UINT8         Event[EventSize]; // The event data
+} TCG_PCR_EVENT;	
+
+typedef UINT32 TCG_PCRINDEX;
+typedef UINT32 TCG_EVENTTYPE;
+typedef UINT8  TCG_DIGEST[20];
+```
+
+\- [_TCG EFI Protocol Specification 5.1_][efi-spec-5_1]
+
+PCRIndex indicates which PCR was extended. The Digest contains the value written to the PCR, and is a hash of the Event (except for some events where it’s the Digest is the value being communicated, e.g. the bootloader hash). The EventType indicates what kind of data is being conveyed.
+
+[efi-spec-5_1]: https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf#page=15
+
+## Event type and verification footguns
+
+To verify a machine’s state, it might seem reasonable to parse the Event Log, replay the Digests against the PCRs to verify it hasn’t been tampered with, then parse data from the log to get things like a machine’s secure boot settings.
+
+This is wrong.
+
+Replaying an Event Log only verifies a subset of the fields in an Event. Specifically, it only guarantees PCRIndex, Digest, and sometimes the event data, but __the EventType isn’t part of the Digest and can be freely modified by an attacker.__
+
+Consider the following event log for secure boot entries (PCR[7]):
+
+```
+PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=53
+PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=842
+PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=1598
+PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=4744
+PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=3762
+PCRIndex=7 EventType=EV_SEPARATOR EventSize=4
+PCRIndex=7 EventType=EV_EFI_VARIABLE_AUTHORITY EventSize=1573
+```
+
+To determine the secure boot state of a device, a parser might reasonably implement the following logic after verifying an event log:
+
+```
+for (event in events) {
+    switch (event.type) {
+        case EV_EFI_VARIABLE_AUTHORITY:
+            // Parse EFI variable for secure boot state
+            // ...
+        case EV_EFI_VARIABLE_DRIVER_CONFIG:
+            // ...
+        case EV_SEPARATOR:
+            // ...
+        case /* more cases */:
+            // ...
+        default:
+            // Ignore unknown event types
+            continue;
+    }
+}
+```
+
+Because of the “default” condition, an attacker can change all existing event log types to a type the parser doesn’t interpret, for example the reserved type EV_UNUSED, then append their own events and extend the PCRs:
+
+```diff
+-PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=53
+-PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=842
+-PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=1598
+-PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=4744
+-PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=3762
+-PCRIndex=7 EventType=EV_SEPARATOR EventSize=4
+-PCRIndex=7 EventType=EV_EFI_VARIABLE_AUTHORITY EventSize=1573
++PCRIndex=7 EventType=EV_UNUSED EventSize=53
++PCRIndex=7 EventType=EV_UNUSED EventSize=842
++PCRIndex=7 EventType=EV_UNUSED EventSize=1598
++PCRIndex=7 EventType=EV_UNUSED EventSize=4744
++PCRIndex=7 EventType=EV_UNUSED EventSize=3762
++PCRIndex=7 EventType=EV_UNUSED EventSize=4
++PCRIndex=7 EventType=EV_UNUSED EventSize=1573
++PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=53
++PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=842
++PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=1598
++PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=4744
++PCRIndex=7 EventType=EV_EFI_VARIABLE_DRIVER_CONFIG EventSize=3762
++PCRIndex=7 EventType=EV_SEPARATOR EventSize=4
++PCRIndex=7 EventType=EV_EFI_VARIABLE_AUTHORITY EventSize=1573
+```
+
+The PCR replay and TPM quote will match this event log, but the parser will skip over the legitimate values and use attacker supplied ones.
+
+Even if the parser exhaustively matches event types, an attacker can masquerade a required event as an optional one in hopes the parser will no-op. For example, consider the following bootloader entries (PCR [4]):
+
+```
+PCRIndex=4 EventType=EV_SEPARATOR EventSize=4
+PCRIndex=4 EventType=EV_EFI_BOOT_SERVICES_APPLICATION EventSize=158
+```
+
+In this case, an attacker can change the bootloader hash event type to an optional event type, then append their own hash. This is especially hard to detect because the Digest of EV_EFI_PLATFORM_FIRMWARE_BLOB and EV_EFI_BOOT_SERVICES_APPLICATION event types aren’t a hash of their event data, so an attacker can also modify the data to match the parser’s expectations too:
+
+```diff
+PCRIndex=4 EventType=EV_SEPARATOR EventSize=4
+-PCRIndex=4 EventType=EV_EFI_BOOT_SERVICES_APPLICATION EventSize=158
++PCRIndex=4 EventType=EV_EFI_PLATFORM_FIRMWARE_BLOB EventSize=124
++PCRIndex=4 EventType=EV_EFI_BOOT_SERVICES_APPLICATION EventSize=158
+```
+
+## Vulnerability report and outcome
+
+This issue was reported to the Trusted Computing Group on September 6th and eventually triaged by their Vulnerability Response Team.
+
+At the time of the report, there was no conical recommendations for how to verify an Event Log and there was no warning in the [Event Log spec][spec-event-logging] that fields are untrusted. The TCG noted that event data is meant for debugging, and that event digests (the values written to the PCRs) are the only fields that should be used for trust decisions. The TCG confirmed that guidance for verifying the Event Log is being drafted. Updated specifications, including a new document, the TCG Firmware Integrity Measurement Specification, have been [released for public review][spec-public-review].The guidance document will be available soon at the same location.
+
+The full 90-day disclosure deadline was requested to determine if other TCG members were vulnerable to this issue.
+
+This issue is a nice reminder that mixing trusted and untrusted data is a recipe for [implementation][saml-sig-wrapping] [vulnerabilities][jwt-header-none]. We plan to update our open source project [go-attestation][go-attestation] to better help users identify what can be used for trust decisions and what’s reserved for debugging.
+
+A special thanks to Amy Nelson, the PC Client Workgroup Chair, for being our point of contact through this process.
+
+[spec-event-logging]: https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientSpecPlat_TPM_2p0_1p04_pub.pdf#page=90
+[spec-event-logging-draft]: https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_05_3feb20.pdf#page=89
+[spec-public-review]: https://trustedcomputinggroup.org/specifications-public-review/
+[saml-sig-wrapping]: https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf
+[jwt-header-none]: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
+[go-attestation]: https://github.com/google/go-attestation