From nobody Sun May 5 04:59:03 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) client-ip=66.175.222.12; envelope-from=bounce+27952+44900+1787277+3901457@groups.io; helo=web01.groups.io; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+44900+1787277+3901457@groups.io; dmarc=fail(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1564991307; cv=none; d=zoho.com; s=zohoarc; b=TVXX+5ilqsMUi2KggkxbIZBlA7eYlC8XEJWfcVAGaCzNSZNXxCdxFoArYk0Zt9s3noso9DSsqW26VO2bNrlqIhpoaaOCKlykHXST+GwQgyBHlxazk9Qma6eK3YSi9wfS6qtzT/KYiaLspqh5hifMltllWE0N5O4AIj9DFJZsiq8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1564991307; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Id:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Sender:Subject:To:ARC-Authentication-Results; bh=F7wj1RBMGOATt0w3PmxKFndOnHGgXxwzLr3XuP5gY5Y=; b=DHDoGp01OYgNFQ1Nvfj2HmIY2BZ14z/1r6F0ifOisFqArrqKhRxC3l76r+z1w2CngRZ5SVHRzJ1ZCLcCsyq8ln/4FiU+et19PanMXFxM7YYpGBA+K7CCehgRfCUT7ZcwywDNfznm8/8S9RQys97W823Q4SOBJSLJ6ifYRxrPFAc= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+44900+1787277+3901457@groups.io; dmarc=fail header.from= (p=none dis=none) header.from= Received: from web01.groups.io (web01.groups.io [66.175.222.12]) by mx.zohomail.com with SMTPS id 1564991307498175.69604344600236; Mon, 5 Aug 2019 00:48:27 -0700 (PDT) Return-Path: X-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 X-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" X-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: [edk2-devel] [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> MIME-Version: 1.0 Precedence: Bulk List-Unsubscribe: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,jiewen.yao@intel.com Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=groups.io; q=dns/txt; s=20140610; t=1564991306; bh=QHBgleM0GB0ixYenI90McqsRWQVizqndfgVWJ0DrrVY=; h=Cc:Content-Type:Date:From:Reply-To:Subject:To; b=jznhMyHHZPMoDuX3j/STdbgHoUfJg7z08IAvx5XGF530btSSUkJp8sd2oEpd/hn6v5r iNg87Njk+CpF+CMuBN5Q3xb26wEsbLCxN9b136agvR9wFVYY8zFFvET8/HZ/0VU7+SYpY eRvlQkuc1Smc4YSDxn2JX9Xo+FKGyKpgSuo= X-ZohoMail-DKIM: pass (identity @groups.io) Content-Type: text/plain; charset="utf-8" This patch adds "Threat model for EDK II" as the appendix section of "EDK II secure coding guide" document. The threat model discussed here is a general guide and serves as the baseli= ne of the EDK II firmware. For each specific feature in EDK II firmware, there mi= ght be additional feature-based threat models in addition to the general threat mo= del. The full gitbook can be also avaiable at https://github.com/jyao1/EDK_II_Secure_Coding_Guide/tree/Threat_model. Cc: Vincent Zimmer Signed-off-by: Jiewen Yao Reviewed-by: Vincent Zimmer Reviewed-by: Vincent Zimmer =20 --- 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 @@ + + +# Appendix:Threat Model for EDK II {#appendix-threat-model-for-edk-ii} +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. + +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)). + +| Threat | Desired Property | +| --- | --- | +| Spoofing | Authentication | +| Tampering | Integrity | +| Repudiation | Non-Repudiation | +| Information Disclosure | Confidentiality | +| Denial of Service | Availability | +| Elevation of Privilege | Authorization | + +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). + +We will consider the below adversary for the EDK II firmware: + +| Adversary | Capability | +| --- | --- | +| Network Attacker | The attacker may connect to the system by network in = order to eavesdrop, intercept, masquerade, or modify the network packet. | +| 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). | +| 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). | +| 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). | +| 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. | + +We will consider the below mitigations for the EDKII firmware: + +| Mitigation | Objective | +| --- | --- | +| Protection | The mitigation is to prevent such an attack for damaging th= e system. | +| Detection | The mitigation is to detect if the system is under attack. | +| Recovery | The mitigation is to recover the system if it is under attack= . | + +* Asset: Flash Content +* Asset: Boot Flow +* Asset: S3 Resume +* Asset: Management Mode +* Asset: Build Tool 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 @@ + + +## Asset: Boot Flow {#asset-boot-flow} + +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). + +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. + +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. + +| Threat | Example | +| --- | --- | +| Spoofing | If the firmware needs to authenticate the user, the attacker = may spoof the identity, or bypass the authentication check. | +| 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. | +| Repudiation | N/A | +| Information Disclosure | The user identity and device password are secre= t information. The attacker may want to steal them. | +| Denial of Service | The attacker may modify the secure boot configuratio= n data to cause a system crash during verification. | +| 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. | + + + +| Adversary | Example | +| --- | --- | +| 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. | +| Unprivileged Software Attacker | The attacker may write a malformed UEFI= authenticated variable to break the secure boot configuration. | +| 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. | +| 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. | +| 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= . | + +| Mitigation | Example | +| --- | --- | +| 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. | +| Detection | N/A | +| Recovery | N/A | 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 @@ + + +## Asset: Build Tool {#asset-build-tool} + +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. + +This is not a traditional attack to the final system, but it represents an= attack to the tool chain in the build environment. + +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. + 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 @@ + + +## Asset: Flash Content {#asset-flash-content} + +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. + +The flash content here includes both firmware code (such as PEI, DXE, SMM = etc) and firmware data (such as UEFI variables, Microcode, etc). + +| Threat | Example | +| --- | --- | +| Spoofing | N/A | +| 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. | +| Repudiation | N/A | +| Information Disclosure | If the system software stores the secret in the= firmware, the attacker may read the firmware content and get the secret. | +| 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. | +| 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. | + +| Adversary | Example | +| --- | --- | +| Network Attacker | If the network is enabled before SMM lock and flash l= ock, the attacker may send mal-formed network packets. | +| Unprivileged Software Attacker | The attacker may trigger a firmware upd= ate, or write the UEFI variable. | +| 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. | +| 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. | +| Skilled Hardware Attacker | N/A | + +| Mitigation | Example | +| --- | --- | +| 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. | +| 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. | +| 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. | 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 @@ + + +## Asset: Management Mode {#asset-management-mode} + +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. + +| Threat | Example | +| --- | --- | +| Spoofing | N/A | +| Tampering | The attacker may update the management mode memory to inject= code or data. | +| Repudiation | N/A | +| 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. | +| 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. | +| 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. | + +| Adversary | Example | +| --- | --- | +| Network Attacker | N/A | +| Unprivileged Software Attacker | N/A | +| 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. | +| Simple Hardware Attacker | N/A | +| Skilled Hardware Attacker | N/A | + +| Mitigation | Example | +| --- | --- | +| 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. | +| Detection | N/A | +| Recovery | N/A | + 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 @@ + + +## Asset: S3 Resume {#asset-s3-resume} + +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. + +All protection applied to the normal boot must also be applied in S3 resum= e. + +| Threat | Example | +| --- | --- | +| Spoofing | N/A | +| Tampering | The attacker may try to modify the S3 configuration, also kn= own as S3 boot script. | +| Repudiation | N/A | +| Information Disclosure | If the s3 configuration includes a secret (such= as HDD password), the attacker may want to steal the secret. | +| Denial of Service | The attacker may destroy the S3 configuration to pre= vent the system from booting. | +| Elevation of Privilege | The attacker may disable the protections stored= in the S3 configuration such as register lock. | + + + +| Adversary | Example | +| --- | --- | +| Network Attacker | N/A | +| Unprivileged Software Attacker | The attacker may write a malformed UEFI= variable to break the S3 configuration. | +| 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. | +| Simple Hardware Attacker | N/A | +| Skilled Hardware Attacker | N/A | + +| Mitigation | Example | +| --- | --- | +| 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. | +| Detection | N/A | +| Recovery | N/A | --=20 2.19.2.windows.1 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44900): https://edk2.groups.io/g/devel/message/44900 Mute This Topic: https://groups.io/mt/32723406/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-