From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.100, mailfrom: jiewen.yao@intel.com) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by groups.io with SMTP; Mon, 05 Aug 2019 00:48:26 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2019 00:47:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,349,1559545200"; d="scan'208";a="372995512" Received: from jyao1-mobl2.ccr.corp.intel.com ([10.239.196.48]) by fmsmga005.fm.intel.com with ESMTP; 05 Aug 2019 00:47:45 -0700 From: "Yao, Jiewen" To: devel@edk2.groups.io Cc: Vincent Zimmer Subject: [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II. Date: Mon, 5 Aug 2019 15:47:33 +0800 Message-Id: <20190805074733.2876-1-jiewen.yao@intel.com> X-Mailer: git-send-email 2.19.2.windows.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This patch adds "Threat model for EDK II" as the appendix section=0D of "EDK II secure coding guide" document.=0D =0D The threat model discussed here is a general guide and serves as the baseli= ne of=0D the EDK II firmware. For each specific feature in EDK II firmware, there mi= ght be=0D additional feature-based threat models in addition to the general threat mo= del.=0D =0D The full gitbook can be also avaiable at=0D https://github.com/jyao1/EDK_II_Secure_Coding_Guide/tree/Threat_model.=0D =0D Cc: Vincent Zimmer Signed-off-by: Jiewen Yao =0D Reviewed-by: Vincent Zimmer =0D --- SUMMARY.md | 6 ++ appendix_threat_model_for_edk_ii/README.md | 70 +++++++++++++++++++ .../asset_boot_flow.md | 63 +++++++++++++++++ .../asset_build_tool.md | 39 +++++++++++ .../asset_flash_content.md | 59 ++++++++++++++++ .../asset_management_mode.md | 58 +++++++++++++++ .../asset_s3_resume.md | 61 ++++++++++++++++ 7 files changed, 356 insertions(+) create mode 100644 appendix_threat_model_for_edk_ii/README.md create mode 100644 appendix_threat_model_for_edk_ii/asset_boot_flow.md create mode 100644 appendix_threat_model_for_edk_ii/asset_build_tool.md create mode 100644 appendix_threat_model_for_edk_ii/asset_flash_content.md create mode 100644 appendix_threat_model_for_edk_ii/asset_management_mode.= md create mode 100644 appendix_threat_model_for_edk_ii/asset_s3_resume.md diff --git a/SUMMARY.md b/SUMMARY.md index dc22f1e..d56dee3 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -38,6 +38,12 @@ * [SMM](secure_coding_guidelines_intel_platforms/smm.md) * [Intel=C2=AE Boot Guard](secure_coding_guidelines_intel_platforms/inte= l_boot_guard.md) * [Intel=C2=AE Bios Guard](secure_coding_guidelines_intel_platforms/inte= l_bios_guard.md) +* [Appendix - Threat Model for EDK II](appendix_threat_model_for_edk_ii/RE= ADME.md) + * [Asset: Flash Content](appendix_threat_model_for_edk_ii/asset_flash_co= ntent.md) + * [Asset: Boot Flow](appendix_threat_model_for_edk_ii/asset_boot_flow.md) + * [Asset: S3 Resume](appendix_threat_model_for_edk_ii/asset_s3_resume.md) + * [Asset: Management Mode](appendix_threat_model_for_edk_ii/asset_manage= ment_mode.md) + * [Asset: Build Tool](appendix_threat_model_for_edk_ii/asset_build_tool.= md) * [References](references.md) * [Books and Papers ](references.md#books-and-papers) * [Web ](references.md#web) diff --git a/appendix_threat_model_for_edk_ii/README.md b/appendix_threat_m= odel_for_edk_ii/README.md new file mode 100644 index 0000000..6c4ac16 --- /dev/null +++ b/appendix_threat_model_for_edk_ii/README.md @@ -0,0 +1,70 @@ +=0D +=0D +# Appendix:Threat Model for EDK II {#appendix-threat-model-for-edk-ii}=0D +This chapter provides the basic assumptions for the threat model of EDK II= firmware. The threat model discussed here is a general guide and serves as= the baseline of the EDK II firmware. For each specific feature in EDK II f= irmware, there might be additional feature-based threat models in addition = to the general threat model.=0D +=0D +In [UEFI Threat Model](https://uefi.org/sites/default/files/resources/Inte= l-UEFI-ThreatModel.pdf), we discussed the asset, threat and mitigation. Her= e we will revisit these items and based upon [STRIDE](https://en.wikipedia.= org/wiki/STRIDE_(security)).=0D +=0D +| Threat | Desired Property |=0D +| --- | --- |=0D +| Spoofing | Authentication |=0D +| Tampering | Integrity |=0D +| Repudiation | Non-Repudiation |=0D +| Information Disclosure | Confidentiality |=0D +| Denial of Service | Availability |=0D +| Elevation of Privilege | Authorization |=0D +=0D +In EDK II firmware, the denial of service can be temporary in the current = boot, or permanent in which case the system never boot again. The latter is= more serious and it is named as permanent denial of service (PDoS).=0D +=0D +We will consider the below adversary for the EDK II firmware:=0D +=0D +| Adversary | Capability |=0D +| --- | --- |=0D +| Network Attacker | The attacker may connect to the system by network in = order to eavesdrop, intercept, masquerade, or modify the network packet. |= =0D +| Unprivileged Software Attacker | The attacker may run ring-3 software in= an OS application layer. The attacker may perform a software based side ch= annel attack (such as using cache timing). |=0D +| System Software Attacker | The attacker may run ring-0 software in the O= S kernel or hypervisor, or run 3rd party firmware code in firmware boot pha= se. The attacker may perform the software based side channel attack (such a= s using cache timing, performance counters, branch information, or power st= atus). |=0D +| Simple Hardware Attacker | The attacker may touch the platform hardware = (such as power button or jumper) and attach/remove a simple malicious devic= e (such as hardware debugger, PCI Leach to the external port, PCIE card to = the PCIE slot, memory DIMM, NIC cable, hard drive, keyboard, USB device, Bl= uetooth device). The attacker may hijack the simple system bus (such as the= SPI bus or I2C bus). |=0D +| Skilled Hardware Attacker | The attacker may hijack the complex system b= us (such as memory bus, or PCI express bus). The attacker may perform the h= ardware based side channel attack, such as power analysis, thermal analysis= , or electromagnetic analysis. The attacker may perform a glitch attack. |= =0D +=0D +We will consider the below mitigations for the EDKII firmware:=0D +=0D +| Mitigation | Objective |=0D +| --- | --- |=0D +| Protection | The mitigation is to prevent such an attack for damaging th= e system. |=0D +| Detection | The mitigation is to detect if the system is under attack. |= =0D +| Recovery | The mitigation is to recover the system if it is under attack= . |=0D +=0D +* Asset: Flash Content=0D +* Asset: Boot Flow=0D +* Asset: S3 Resume=0D +* Asset: Management Mode=0D +* Asset: Build Tool=0D diff --git a/appendix_threat_model_for_edk_ii/asset_boot_flow.md b/appendix= _threat_model_for_edk_ii/asset_boot_flow.md new file mode 100644 index 0000000..0d132c6 --- /dev/null +++ b/appendix_threat_model_for_edk_ii/asset_boot_flow.md @@ -0,0 +1,63 @@ +=0D +=0D +## Asset: Boot Flow {#asset-boot-flow}=0D +=0D +The main system firmware work is to initialize the silicon and then transf= er control to an operating system. Because the firmware is almost the first= component running on the system, another responsibility of the system firm= ware is to maintain the secure boot chain (defined in UEFI specification) a= nd the trusted boot chain (defined by TCG).=0D +=0D +Here the secure boot chain means that the first entity needs to verify if = the second entity is good before running it, not run the second entity if t= he verification fails. The trusted boot chain means that the first entity n= eeds to measure the second entity before running it and then always run the= second entity. The attestation may happen later. The system firmware needs= to maintain both boot flows carefully. The verification and measurement mu= st not be bypassed.=0D +=0D +In addition, the system firmware may need to authenticate the end user, to= determine if the user is authorized to perform some action. For example, t= he user may be asked to input a hard driver password to continue the boot. = Or the user may be asked to input an administrator password to enter a setu= p page. Those actions must not be bypassed as well.=0D +=0D +| Threat | Example |=0D +| --- | --- |=0D +| Spoofing | If the firmware needs to authenticate the user, the attacker = may spoof the identity, or bypass the authentication check. |=0D +| Tampering | The attacker may want to modify the secure boot logic or tru= sted boot logic (either code or configuration data) to bypass the verificat= ion or measurement. |=0D +| Repudiation | N/A |=0D +| Information Disclosure | The user identity and device password are secre= t information. The attacker may want to steal them. |=0D +| Denial of Service | The attacker may modify the secure boot configuratio= n data to cause a system crash during verification. |=0D +| Elevation of Privilege | If the attacker bypasses the user authenticatio= n, he or she may enter firmware setup page to modify the configuration.If t= he attacker bypasses the secure boot verification, he or she may run the un= authorized 3rd part code in the ring-0 environment. |=0D +=0D +=0D +=0D +| Adversary | Example |=0D +| --- | --- |=0D +| Network Attacker | The attacker may send malformed network packets to in= ject code into the system.
The attacker may send a bad UEFI image to byp= ass or break the secure boot logic. |=0D +| Unprivileged Software Attacker | The attacker may write a malformed UEFI= authenticated variable to break the secure boot configuration. |=0D +| System Software Attacker | The attacker may send a command to the isolat= ed execution environment in order to modify the secure boot configuration.<= BR>The attacker may enable a side channel to get secrets from memory. |=0D +| Simple Hardware Attacker | The attacker may attach PCI Leach to perform = DMA attack to read the secret from memory, or write the code region to bypa= ss the verification. |=0D +| Skilled Hardware Attacker | The attacker may hijack the memory bus to re= ad secrets from memory, or write the code region to bypass the verification= . |=0D +=0D +| Mitigation | Example |=0D +| --- | --- |=0D +| Protection | Do check for untrusted external input before use (such as n= etwork packet, option ROM, OS loader, and UEFI authenticated variable). Do = not run any untrusted 3rd part code before verification.
If the secret i= s generated, it must be cleared after use (such as temporary input from HII= ). If the secret needs to be stored, the choice includes: to save secret to= hardware directly (such as OPAL password), to save hash plus salt to a UEF= I variable (such as user password), to save the secret in an isolated envir= onment (such as TPM MOR2). Side channel prevention must be applied in this = case.
DMA protection must be enabled. Memory encryption must be used if = the memory bus attack is in scope. |=0D +| Detection | N/A |=0D +| Recovery | N/A |=0D diff --git a/appendix_threat_model_for_edk_ii/asset_build_tool.md b/appendi= x_threat_model_for_edk_ii/asset_build_tool.md new file mode 100644 index 0000000..d258a10 --- /dev/null +++ b/appendix_threat_model_for_edk_ii/asset_build_tool.md @@ -0,0 +1,39 @@ +=0D +=0D +## Asset: Build Tool {#asset-build-tool}=0D +=0D +In 1983, Ken Thompson received the Turing Award with Dennis Ritchie. There= he delivered a speech - [Reflections on Trusting Trust](https://www.archiv= e.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf), and demonstrate= d how to inject a Trojan Horse into the compiler. Afterward the compiler ge= nerated a buggy binary. It is not impossible.=0D +=0D +This is not a traditional attack to the final system, but it represents an= attack to the tool chain in the build environment.=0D +=0D +The mitigation is: only trust the tool chain from a trusted source with th= e source code, and protect the tool chain in the build environment.=0D +=0D diff --git a/appendix_threat_model_for_edk_ii/asset_flash_content.md b/appe= ndix_threat_model_for_edk_ii/asset_flash_content.md new file mode 100644 index 0000000..bb7c3c8 --- /dev/null +++ b/appendix_threat_model_for_edk_ii/asset_flash_content.md @@ -0,0 +1,59 @@ +=0D +=0D +## Asset: Flash Content {#asset-flash-content}=0D +=0D +NIST [SP 800-147](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialp= ublication800-147.pdf) and [SP 800-147B](https://nvlpubs.nist.gov/nistpubs/= SpecialPublications/NIST.SP.800-147B.pdf) provide system firmware protectio= n guidelines, including the detailed information on system firmware protect= ion and update. NIST [SP 800-193](https://nvlpubs.nist.gov/nistpubs/Special= Publications/NIST.SP.800-193.pdf) provides platform firmware resiliency gui= delines. It extends protection to 3 principles: protection, detection, and = recovery. It also enlarges the scope from system firmware (BIOS) to all the= firmware on the platform.=0D +=0D +The flash content here includes both firmware code (such as PEI, DXE, SMM = etc) and firmware data (such as UEFI variables, Microcode, etc).=0D +=0D +| Threat | Example |=0D +| --- | --- |=0D +| Spoofing | N/A |=0D +| Tampering | If the firmware is not protected or locked, the attacker mig= ht modify the firmware directly.
If the firmware update process is not a= uthenticated, the attacker might send a malicious firmware update image for= update. |=0D +| Repudiation | N/A |=0D +| Information Disclosure | If the system software stores the secret in the= firmware, the attacker may read the firmware content and get the secret. |= =0D +| Denial of Service | If the attacker can modify the firmware content (cod= e or data) and cause the firmware crash, the system might no longer boot. I= t becomes a permanent denial of service. |=0D +| Elevation of Privilege | If the attacker can modify the firmware content= (code or data) and store a Trojan in firmware, the Trojan may hide itself = and gain the higher privilege. |=0D +=0D +| Adversary | Example |=0D +| --- | --- |=0D +| Network Attacker | If the network is enabled before SMM lock and flash l= ock, the attacker may send mal-formed network packets. |=0D +| Unprivileged Software Attacker | The attacker may trigger a firmware upd= ate, or write the UEFI variable. |=0D +| System Software Attacker | The attacker may access a silicon register to= unlock the flash access register.
The attacker may create a race condit= ion to break the flash write protection or flash update authentication. |=0D +| Simple Hardware Attacker | The attacker may press the power button durin= g flash update or recovery, or set a jumper to modify the system boot mode = from normal boot to recovery or even manufacturing mode.
The attacker ma= y attach PCI Leach to perform DMA attack during flash update or recovery.The attacker may hijack the SPI bus to read or write to the chip data. |= =0D +| Skilled Hardware Attacker | N/A |=0D +=0D +| Mitigation | Example |=0D +| --- | --- |=0D +| Protection | For the code region, the flash write protection must always= be applied. During the flash update, the new firmware image must be authen= ticated and the version must be checked to prevent a rollback attack. In or= der to mitigate Time-of-check/Time-of-use (TOC/TOU) attacks, the new image = must be copied to a secure environment before the check. The DMA protection= must be enabled during flash update.
For the data region, the UEFI auth= enticated variable write must happen in an isolated execution environment. = The authenticated variable data must be authenticated and the rollback prot= ection must be applied. Just as in code region protection, in order to miti= gate TOC/TOU attack, new variable content must be copied to a secure enviro= nment before the check and DMA protection must be applied to this environme= nt. In addition, the secret must not be saved to the firmware code or data = region. |=0D +| Detection | The detection happens in the next boot.
For the code regi= on, the industry may have different solutions to make sure the initial boot= code is unmodified, such as Project Cerberus, Intel=C2=AE Boot Guard, etc.=
For the data region, the UEFI variable driver needs to detect if the va= riable region is modified without using UEFI variable services. |=0D +| Recovery | If something wrong is detected, the entity which detects the = failure needs to start the recovery process, and the recovery data must be = in a known good and secure configuration and be delivered from a trusted an= d always available source. |=0D diff --git a/appendix_threat_model_for_edk_ii/asset_management_mode.md b/ap= pendix_threat_model_for_edk_ii/asset_management_mode.md new file mode 100644 index 0000000..d5028b7 --- /dev/null +++ b/appendix_threat_model_for_edk_ii/asset_management_mode.md @@ -0,0 +1,58 @@ +=0D +=0D +## Asset: Management Mode {#asset-management-mode}=0D +=0D +Management mode is a special system execution environment. X86 systems hav= e system management mode (SMM), and ARM has ARM TrustZone. The firmware cod= e in management mode is considered as a secure world and having high privil= ege.=0D +=0D +| Threat | Example |=0D +| --- | --- |=0D +| Spoofing | N/A |=0D +| Tampering | The attacker may update the management mode memory to inject= code or data. |=0D +| Repudiation | N/A |=0D +| Information Disclosure | The management mode may contain a secret (such = as password, TPM MOR2 entropy), or its own information (code and data struc= ture location). This information may be exposed to normal world. |=0D +| Denial of Service | The management mode only has limited resource (such = as memory). The attacker may send command to management mode code to make i= t run out of resource. |=0D +| Elevation of Privilege | The attacker may gain unauthorized execution ri= ghts in management mode. For example, if the management code calls the norm= al world code, the attacker may replace the original code with malicious co= de to gain the privilege.
The attacker may construct a confused-deputy a= ttack for management mode. For example, the OS kernel may send a command to= management mode to let it modify the hypervisor memory or management mode = memory. |=0D +=0D +| Adversary | Example |=0D +| --- | --- |=0D +| Network Attacker | N/A |=0D +| Unprivileged Software Attacker | N/A |=0D +| System Software Attacker | The attacker may take advantage of an impleme= ntation flaw in the management mode code to read or modify the management m= ode content, or content of a higher privilege environment, such as a hyperv= isor.
The attacker may use a side channel to steal a secret in the manag= ement mode memory. |=0D +| Simple Hardware Attacker | N/A |=0D +| Skilled Hardware Attacker | N/A |=0D +=0D +| Mitigation | Example |=0D +| --- | --- |=0D +| Protection | The management mode code must lock the management mode afte= r it is constructed, no later than 3rd part code running.
The management= mode code must not call out to the normal world code.
The system must r= emove unnecessary management mode handlers.
The required management mode= handler must check the untrusted external input, including the communicati= on buffer, the pointer inside of the communication buffer, the general purp= ose register served as communication buffer pointer, the hardware base addr= ess register. The checked content must be copied into management mode memor= y to prevent TOC/TOU.
The management mode handler must prevent unauthori= zed access to itself and high privileged content such as hypervisor or OS k= ernel memory.
The management mode handler must prevent side channel atta= cks for the secret.
The management mode handler must not allocate more r= esources to serve the request. If additional sources are allocated, they mu= st be freed before the handler return to the normal world. |=0D +| Detection | N/A |=0D +| Recovery | N/A |=0D +=0D diff --git a/appendix_threat_model_for_edk_ii/asset_s3_resume.md b/appendix= _threat_model_for_edk_ii/asset_s3_resume.md new file mode 100644 index 0000000..c514460 --- /dev/null +++ b/appendix_threat_model_for_edk_ii/asset_s3_resume.md @@ -0,0 +1,61 @@ +=0D +=0D +## Asset: S3 Resume {#asset-s3-resume}=0D +=0D +S3 resume is a special boot flow. It is defined by ACPI specification. Dur= ing S3 resume, the system restores the configuration from a normal boot and= jumps to OS waking vector.=0D +=0D +All protection applied to the normal boot must also be applied in S3 resum= e.=0D +=0D +| Threat | Example |=0D +| --- | --- |=0D +| Spoofing | N/A |=0D +| Tampering | The attacker may try to modify the S3 configuration, also kn= own as S3 boot script. |=0D +| Repudiation | N/A |=0D +| Information Disclosure | If the s3 configuration includes a secret (such= as HDD password), the attacker may want to steal the secret. |=0D +| Denial of Service | The attacker may destroy the S3 configuration to pre= vent the system from booting. |=0D +| Elevation of Privilege | The attacker may disable the protections stored= in the S3 configuration such as register lock. |=0D +=0D +=0D +=0D +| Adversary | Example |=0D +| --- | --- |=0D +| Network Attacker | N/A |=0D +| Unprivileged Software Attacker | The attacker may write a malformed UEFI= variable to break the S3 configuration. |=0D +| System Software Attacker | The attacker may send a command to the isolat= ed execution environment to modify the S3 configuration. If there is a secr= et saved in the isolated environment, the attacker may send a commend to ge= t the secret, or use a side channel to steal the secret. |=0D +| Simple Hardware Attacker | N/A |=0D +| Skilled Hardware Attacker | N/A |=0D +=0D +| Mitigation | Example |=0D +| --- | --- |=0D +| Protection | The S3 configuration data must be saved to a secure place. = For example, embedded into read only code region, a read only variable, an = isolated execution environment, or a lock box.
If the S3 configuration d= ata is secret, then it must be saved in an isolated execution environment o= r a lock box to prevent unauthorized reads. |=0D +| Detection | N/A |=0D +| Recovery | N/A |=0D --=20 2.19.2.windows.1