├── CVE-2003-0962 ├── CVE-2006-1060 ├── CVE-2008-1530 ├── CVE-2008-3908 ├── CVE-2016-1734 ├── CVE-2016-8672 ├── CVE-2016-8673 ├── CVE-2017-7932 ├── CVE-2017-7936 ├── CVE-2018-18439 ├── CVE-2018-18440 ├── CVE-2019-5478 ├── CVE-2020-10648 ├── CVE-2020-11683 ├── CVE-2020-11684 ├── CVE-2020-12787 ├── CVE-2020-12788 ├── CVE-2020-12789 ├── CVE-2021-36133 ├── CVE-2021-44149 ├── README.md ├── Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt ├── Security_Advisory-Ref_FSC-HWSEC-VR2020-0001-U-Boot_verified_boot_bypass.txt ├── Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt ├── Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt ├── Security_Advisory-Ref_FSC-HWSEC-VR2021-0001-OP-TEE_TrustZone_bypass.txt ├── Security_Advisory-Ref_FSC-HWSEC-VR2021-0002-OP-TEE_TrustZone_bypass_at_wakeup.txt ├── Security_Advisory-Ref_GLSA200312-03-rsync_heap_overflow.txt ├── Security_Advisory-Ref_GLSA200604-10-zgv_heap_overflow.txt ├── Security_Advisory-Ref_IPVR2016-0001_AppleUSBNetworking_memory_corruption.txt ├── Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt ├── Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt ├── Security_Advisory-Ref_oCERT-2008-001-GnuPG_memory_corruption.txt ├── Security_Advisory-Ref_oCERT-2008-014-WordNet_stack_overflows.txt └── ssa-603476.pdf /CVE-2003-0962: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_GLSA200312-03-rsync_heap_overflow.txt -------------------------------------------------------------------------------- /CVE-2006-1060: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_GLSA200604-10-zgv_heap_overflow.txt -------------------------------------------------------------------------------- /CVE-2008-1530: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_oCERT-2008-001-GnuPG_memory_corruption.txt -------------------------------------------------------------------------------- /CVE-2008-3908: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_oCERT-2008-014-WordNet_stack_overflows.txt -------------------------------------------------------------------------------- /CVE-2016-1734: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_IPVR2016-0001_AppleUSBNetworking_memory_corruption.txt -------------------------------------------------------------------------------- /CVE-2016-8672: -------------------------------------------------------------------------------- 1 | ssa-603476.pdf -------------------------------------------------------------------------------- /CVE-2016-8673: -------------------------------------------------------------------------------- 1 | ssa-603476.pdf -------------------------------------------------------------------------------- /CVE-2017-7932: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt -------------------------------------------------------------------------------- /CVE-2017-7936: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt -------------------------------------------------------------------------------- /CVE-2018-18439: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt -------------------------------------------------------------------------------- /CVE-2018-18440: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt -------------------------------------------------------------------------------- /CVE-2019-5478: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt -------------------------------------------------------------------------------- /CVE-2020-10648: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2020-0001-U-Boot_verified_boot_bypass.txt -------------------------------------------------------------------------------- /CVE-2020-11683: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt -------------------------------------------------------------------------------- /CVE-2020-11684: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt -------------------------------------------------------------------------------- /CVE-2020-12787: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt -------------------------------------------------------------------------------- /CVE-2020-12788: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt -------------------------------------------------------------------------------- /CVE-2020-12789: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt -------------------------------------------------------------------------------- /CVE-2021-36133: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2021-0001-OP-TEE_TrustZone_bypass.txt -------------------------------------------------------------------------------- /CVE-2021-44149: -------------------------------------------------------------------------------- 1 | Security_Advisory-Ref_FSC-HWSEC-VR2021-0002-OP-TEE_TrustZone_bypass_at_wakeup.txt -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | The following advisories cover security issues discovered, or contributed, by 4 | the team at [F-Secure](https://foundry.f-secure.com) Hardware Security Team, 5 | previously known as [Inverse Path](https://www.inversepath.com). 6 | 7 | | CVEs | Description | Advisory 8 | |---------------------------------------------------------------------------------|------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 9 | | [CVE-2021-44149](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44149) | OP-TEE TrustZone bypass at wakeup on NXP i.MX6UL | [Security_Advisory-Ref_FSC-HWSEC-VR2021-0002-OP-TEE_TrustZone_bypass_at_wakeup.txt](https://github.com/f-secure-foundry/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2021-0002-OP-TEE_TrustZone_bypass_at_wakeup.txt) | 10 | | [CVE-2021-36133](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36133) | OP-TEE TrustZone bypass on multiple NXP i.MX models | [Security_Advisory-Ref_FSC-HWSEC-VR2021-0001-OP-TEE_TrustZone_bypass.txt](https://github.com/f-secure-foundry/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2021-0001-OP-TEE_TrustZone_bypass.txt) | 11 | | [CVE-2020-12789](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12789) | ATSAMA5 hardcoded keys are used for protecting applets | [Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt) | 12 | | [CVE-2020-12788](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12788) | ATSAMA5 CMAC verification susceptible to side channel attacks | [Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt) | 13 | | [CVE-2020-12787](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12787) | ATSAMA5 improper applet verification | [Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt) | 14 | | [CVE-2020-11684](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11683) | AT91bootstrap code authentication bypass via key leak | [Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt) | 15 | | [CVE-2020-11683](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11684) | AT91bootstrap timing side channel in CMAC verification | [Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt) | 16 | | [CVE-2020-10648](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10648) | U-Boot verified boot bypass via improper signature verification | [Security_Advisory-Ref_FSC-HWSEC-VR2020-0001-U-Boot_verified_boot_bypass.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2020-0001-U-Boot_verified_boot_bypass.txt) | 17 | | [CVE-2019-5478](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5478) | Xilinx ZU+ Encrypt Only Secure boot bypass via partition header | [Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt) | 18 | | [CVE-2019-5478](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5478) | Xilinx ZU+ Encrypt Only Secure boot bypass via boot header | [Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt) | 19 | | [CVE-2018-18440](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18440) | U-Boot verified boot bypass via network load | [Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt) | 20 | | [CVE-2018-18439](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18439) | U-Boot verified boot bypass via filesystem load | [Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt) | 21 | | [CVE-2017-7936](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7936) | NXP High Assurance Boot SDP protection bypass | [Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt) | 22 | | [CVE-2017-7932](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7932) | NXP High Assurance Boot X.509 parsing error | [Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt) | 23 | | [CVE-2016-8672](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8672) | Siemens SIMATIC missing cookie protection | [SSA-603476](https://github.com/inversepath/advisories/blob/master/ssa-603476.pdf) | 24 | | [CVE-2016-8673](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8673) | Siemens SIMATIC cross-site request forgery | [SSA-603476](https://github.com/inversepath/advisories/blob/master/ssa-603476.pdf) | 25 | | [CVE-2016-1734](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1734) | AppleUSBNetworking memory corruption | [Security_Advisory-Ref_IPVR2016-0001_AppleUSBNetworking_memory_corruption.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_IPVR2016-0001_AppleUSBNetworking_memory_corruption.txt) | 26 | | [CVE-2008-3908](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3908) | WordNet stack and heap overflows | [Security_Advisory-Ref_oCERT-2008-014-WordNet_stack_overflows.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_oCERT-2008-014-WordNet_stack_overflows.txt) | 27 | | [CVE-2008-1530](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1530) | GnuPG memory corruption | [Security_Advisory-Ref_oCERT-2008-001-GnuPG_memory_corruption.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_oCERT-2008-001-GnuPG_memory_corruption.txt) | 28 | | [CVE-2006-1060](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1060) | zgv/xzgv heap overflow | [Security_Advisory-Ref_GLSA200604-10-zgv_heap_overflow.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_GLSA200604-10-zgv_heap_overflow.txt) | 29 | | [CVE-2003-0962](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0962) | rsync heap-based buffer overflow | [Security_Advisory-Ref_GLSA200312-03-rsync_heap_overflow.txt](https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_GLSA200312-03-rsync_heap_overflow.txt) | 30 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt: -------------------------------------------------------------------------------- 1 | Security advisory: Xilinx ZU+ Encrypt Only Secure Boot bypass 2 | ============================================================= 3 | 4 | The Xilinx Zynq UltraScale+ (ZU+) family of System-on-Chip (SoC) devices 5 | supports a secure boot mode referred to as "encrypt only". 6 | 7 | The encrypt only mode is an alternative to the "hardware root of trust" one, 8 | allowing secure boot without asymmetric authentication but which instead, 9 | quoting the ZU+ reference manual ([1] p279), "requires that all configuration 10 | loaded must be encrypted and authenticated using AES-GCM". 11 | 12 | Two design flaws have been identified that allow to execute arbitrary code, 13 | resulting in loss of authentication and confidentiality, leveraging on the lack 14 | of authentication for boot metadata, by means of boot image tampering. 15 | 16 | The flaws spawn from the lack of authentication for execution addresses 17 | specified in headers loaded early in the boot stage. 18 | 19 | Such headers are not encrypted and, lacking authentication, allow an external 20 | attacker to control, with some restrictions, loaded code execution addresses. 21 | 22 | The first design flaw is present in the boot header parsing, performed by the 23 | ZU+ internal boot ROM. Given that the internal boot ROM cannot be updated, only 24 | a new silicon revision by Xilinx, with an adequately patched boot ROM, can 25 | address the first vulnerability. 26 | 27 | The second flaw is present in the partition header table parsing, performed by 28 | the first-stage boot loader (FSBL). The second vulnerability can be addressed 29 | by software means, implementing authentication of the partition header, its 30 | resolution however cannot result in a safe use of the encrypt only mode as long 31 | as the first vulnerability remains unresolved. 32 | 33 | Loss of authentication allows the adversary sufficient control of the system 34 | such that loss of confidentiality can occur as well. 35 | 36 | It is highly recommended, for implementers of any secure boot or trust scheme 37 | which involves encryption, using ZU+ P/Ns, to only use the "hardware root of 38 | trust" mode. 39 | 40 | Xilinx ZU+ lack of authentication for boot header in encrypt only secure boot 41 | ----------------------------------------------------------------------------- 42 | 43 | The first-stage boot loader (FSBL) execution address is a parameter included in 44 | the boot header, the first section of the boot image loaded by the ZU+ internal 45 | boot ROM. 46 | 47 | By design, the boot header is not authenticated under the "encrypt only" secure 48 | boot mode, this opens up the possibility of malicious tampering of the FSBL 49 | execution address, in a manner that allows arbitrary code execution. 50 | 51 | Such tampering can occur when a malicious party has the opportunity of 52 | modifying the boot header contents, for example by means of local boot device 53 | (e.g. SD) tampering. 54 | 55 | As a constraint to exploitation, the FSBL execution address must point to the 56 | On-chip memory (OCM) region. This means that the execution address cannot be 57 | directly pointed at arbitrarily controlled plaintext code stored in external 58 | memories (e.g. QSPI). 59 | 60 | This aspect does not prevent the possibility to exploit the issues, but merely 61 | increases the difficulty required. A feasible scenario would be identifying a 62 | ROP “gadget” or jump, within the FSBL payload, which would allow to bypass the 63 | “encryption only” strategy enforcement. 64 | 65 | Xilinx ZU+ lack of authentication for partition headers in encrypt only secure boot 66 | ----------------------------------------------------------------------------------- 67 | 68 | The destination execution address for boot partitions is a parameter included 69 | in partition headers, sections of the boot image loaded by first-stage boot 70 | loader (FSBL). 71 | 72 | By design, the partition headers are not authenticated under the "encrypt only" 73 | secure boot mode, this opens up the possibility of malicious tampering of the 74 | destination execution address, in a manner that allows arbitrary code 75 | execution. 76 | 77 | Such tampering can occur when a malicious party has the opportunity of 78 | modifying the boot header contents, for example by means of local boot device 79 | (e.g. SD) tampering. 80 | 81 | The exploitation of the destination execution address lack of authentication 82 | does not pose challenges as it can be manipulated to point at the partition 83 | header itself, which can be modified to include valid instructions and 84 | therefore achieving arbitrary code execution. 85 | 86 | Affected versions 87 | ----------------- 88 | 89 | All Xilinx Zynq UltraScale+ P/Ns are believed to be vulnerable, tests have been 90 | performed against an Xilinx Zynq UltraScale+ MPSoC ZCU104 Evaluation Kit. 91 | 92 | Given that the internal boot ROM cannot be updated, only a new silicon revision 93 | by Xilinx, with an adequately patched boot ROM, can address the boot header 94 | lack of authentication. 95 | 96 | The partition header lack of authentication can be theoretically addressed with 97 | an FSBL patch, though none is available at this time. 98 | 99 | Credit 100 | ------ 101 | 102 | Vulnerabilities discovered and reported by the Inverse Path team at F-Secure, 103 | in collaboration with Robert Bosch GmbH. 104 | 105 | CVE 106 | --- 107 | 108 | CVE-2019-5478: Xilinx ZU+ lack of authentication for boot header in encrypt only secure boot 109 | CVE-2019-5478: Xilinx ZU+ lack of authentication for partition headers in encrypt only secure boot 110 | 111 | Timeline 112 | -------- 113 | 114 | 2019-06-21: findings identified during a security audit by Inverse Path team at 115 | F-Secure in collaboration with Robert Bosch GmbH. 116 | 117 | 2019-06-25: findings shared with Bosch PSIRT. 118 | 119 | 2019-06-28: findings shared with Xilinx PSIRT. 120 | 121 | 2019-07-05: Xilinx PSIRT confirms the findings. 122 | 123 | 2019-07-15: Xilinx PSIRT agrees to public disclosure process, consisting of a 124 | Security Design Advisory and updates to the Technical Reference Manual. 125 | 126 | 2019-08-12: Xilinx Design Advisory [2] and F-Secure advisory [3] release. 127 | 128 | 2019-09-03: Xilinx communicates assigned CVE. 129 | 130 | References 131 | ---------- 132 | 133 | [1] https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf 134 | [2] https://www.xilinx.com/support/answers/72588.html 135 | 136 | Permalink 137 | --------- 138 | 139 | [3] https://github.com/f-secure-foundry/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt 140 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_FSC-HWSEC-VR2020-0001-U-Boot_verified_boot_bypass.txt: -------------------------------------------------------------------------------- 1 | Improper image signature verification 2 | ===================================== 3 | 4 | Description 5 | ----------- 6 | 7 | Das U-Boot typically is employed as a second-stage boot loader responsible for 8 | loading the Linux operating system's kernel and related images and passing 9 | control further to the OS. The bootloader is also responsible to verify 10 | integrity and authenticity of the loaded images to ensure only authentic 11 | software is allowed to run. U-Boot's verified boot feature [1,2] is used to 12 | achieve this. This method only applies to the flattened image tree (FIT) image 13 | format. 14 | 15 | The FIT image is based on previously developed device tree format used in both 16 | U-Boot and the Linux kernel to store and pass configuration information. An 17 | example image tree source (the text format used to generate FIT images) from 18 | the documentation is reproduced below to illustrate the concept: 19 | 20 | ``` 21 | / { 22 | images { 23 | kernel-1 { 24 | data = 25 | hash-1 { 26 | algo = "sha1"; 27 | value = <...kernel hash 1...> 28 | }; 29 | }; 30 | kernel-2 { 31 | data = 32 | hash-1 { 33 | algo = "sha1"; 34 | value = <...kernel hash 2...> 35 | }; 36 | }; 37 | fdt-1 { 38 | data = ; 39 | hash-1 { 40 | algo = "sha1"; 41 | value = <...fdt hash 1...> 42 | }; 43 | }; 44 | fdt-2 { 45 | data = ; 46 | hash-1 { 47 | algo = "sha1"; 48 | value = <...fdt hash 2...> 49 | }; 50 | }; 51 | }; 52 | configurations { 53 | default = "conf-1"; 54 | conf-1 { 55 | kernel = "kernel-1"; 56 | fdt = "fdt-1"; 57 | signature-1 { 58 | algo = "sha1,rsa2048"; 59 | value = <...conf 1 signature...>; 60 | }; 61 | }; 62 | conf-2 { 63 | kernel = "kernel-2"; 64 | fdt = "fdt-2"; 65 | signature-1 { 66 | algo = "sha1,rsa2048"; 67 | value = <...conf 1 signature...>; 68 | }; 69 | }; 70 | }; 71 | }; 72 | ``` 73 | 74 | This image tree source describes two kernels with two flattened device tree 75 | blobs (FDTs) as well as two configurations denoting which images are to be 76 | used together. The complete configuration may also include other images e.g. 77 | RAM disks. Hash values for individual images are computed during image build. 78 | 79 | When an image is signed using the mkimage tool provided with U-Boot, the image 80 | is modified by adding several properties to corresponding signature nodes, 81 | specifically `hashed-strings`, `hashed-nodes`, `timestamp`, `signer-version`, 82 | `signer-name`, and `value`. The `value` property holds the actual signature, 83 | while the `hashed-strings` and `hashed-nodes` properties represent the elements 84 | that were used to compute the signed hash value. For example: 85 | 86 | ``` 87 | conf@1 { 88 | description = [REMOVED]; 89 | kernel = "kernel@1"; 90 | fdt = "fdt@1"; 91 | ramdisk = "ramdisk@1"; 92 | signature@1 { 93 | hashed-strings = [00 00 00 00 00 00 00 8e]; 94 | hashed-nodes = "/", "/configurations/conf@1", "/images/fdt@1", "/images/fdt@1/hash@1", "/images/kernel@1", "/images/kernel@1/hash@1", "/images/ramdisk@1", "/images/ramdisk@1/hash@1"; 95 | timestamp = [5d cb 49 dc]; 96 | signer-version = "2019.07"; 97 | signer-name = "mkimage"; 98 | value = [03 d9 d7 e8 5a cf ..]; 99 | algo = "sha256,rsa4096"; 100 | key-name-hint = [REMOVED]; 101 | sign-images = "fdt", "kernel", "ramdisk"; 102 | }; 103 | }; 104 | ``` 105 | 106 | The string block data starting from offset 0 to offset 0x8E was included in the 107 | hash computation along with enumarated tree nodes, which produces the given RSA 108 | signature. 109 | 110 | It was found that U-Boot does not verify the contents of `hashed-nodes` 111 | correlate with the sub-images required to be loaded by the configuration, 112 | specified e.g. in the `kernel`, `fdt`, and `ramdisk` configuration properties. 113 | This allows to craft another configuration with the same signature node but 114 | referencing a different sub-image(s): 115 | 116 | ``` 117 | conf@2 { 118 | description = "Super 1337 Configuration"; 119 | kernel = "kernel@2"; 120 | fdt = "fdt@1"; 121 | ramdisk = "ramdisk@1"; 122 | signature@1 { 123 | hashed-strings = [00 00 00 00 00 00 00 8e]; 124 | hashed-nodes = "/", "/configurations/conf@1", "/images/fdt@1", "/images/fdt@1/hash@1", "/images/kernel@1", "/images/kernel@1/hash@1", "/images/ramdisk@1", "/images/ramdisk@1/hash@1"; 125 | timestamp = [5d cb 49 dc]; 126 | signer-version = "2019.07"; 127 | signer-name = "mkimage"; 128 | value = [03 d9 d7 e8 5a cf ..]; 129 | algo = "sha256,rsa4096"; 130 | key-name-hint = [REMOVED]; 131 | sign-images = "fdt", "kernel", "ramdisk"; 132 | }; 133 | }; 134 | ``` 135 | 136 | As by design [3] only certain parts of the FIT image are hashed, it is possible 137 | to insert arbitrary FIT nodes after configurations have been signed without 138 | invalidating any signatures, adding both arbitrary configurations as well as 139 | arbitrary sub-images. Note that this fact is explicitly documented. It is also 140 | possible to change the default property of the configurations node to suggest 141 | the crafted configuration to be chosen. 142 | 143 | Impact 144 | ------ 145 | 146 | An attacker having a properly signed FIT image is able to craft arbitrary FIT 147 | images that would pass signature validation, resulting in booting and 148 | execution of untrusted code. 149 | 150 | The exploitation relies on the fact that the crafted configuration will be 151 | chosen to be booted. This may occur, for example, when the attacker is able to 152 | modify the `default` property of the `configurations` node and the setup does 153 | not explicitly choose to boot a specific configuration. Consequently, one way of 154 | mitigating the issue is to explicitly specify the configuration name as part of 155 | the `bootm` command arguments, for example: `bootm ${loadaddr}#conf@1 - ${fdtaddr}` 156 | 157 | Affected versions 158 | ----------------- 159 | 160 | U-Boot versions 2018.03 and 2020.01 were verified to be affected. Versions 161 | prior to 2018.03 may be affected as well. 162 | 163 | Solution 164 | -------- 165 | 166 | Apply patches or update to a fixed version when available. 167 | 168 | Preliminary patches have been posted to the mailing list [4] for review. 169 | 170 | CVE assignment 171 | -------------- 172 | 173 | CVE-2020-10648 should be used to track this issue. 174 | 175 | Credit 176 | ------ 177 | 178 | Dmitry Janushkevich (@infosecdj) of the Hardware Security team, F-Secure 179 | 180 | Timeline 181 | -------- 182 | 183 | 2020-01-22: Discovery of the issue. 184 | 2020-01-24: Details sent to maintainers Tom Rini and Simon Glass. 185 | 2020-02-26: Patches provided for review by Simon Glass. 186 | 2020-03-11: Release date agreed to be March 18. 187 | 2020-03-17: CVE assignment. 188 | 2020-03-18: Public release. 189 | 190 | References 191 | ---------- 192 | 193 | [1] https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/verified-boot.txt 194 | [2] https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt 195 | [3] See documentation for the fdt_find_regions() function in include/linux/libfdt.h 196 | [4] https://lists.denx.de/pipermail/u-boot/2020-March/403409.html 197 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_FSC-HWSEC-VR2020-0002-AT91Bootstrap_code_authentication_issues.txt: -------------------------------------------------------------------------------- 1 | Security advisory: Microchip AT91Bootstrap Code Authentication Issues 2 | ===================================================================== 3 | 4 | The AT91Bootstrap project [1] is the 2nd level bootloader for certain families 5 | of Microchip (formerly Atmel) microprocessors (aka AT91). It providing a set 6 | of algorithms to manage the hardware initialization, download the next boot 7 | stage from specified media, authenticate it, and start it. 8 | 9 | Two issues were identified in the code authentication functionality which 10 | allow attackers with physical access to disclose encryption keys and conduct 11 | side channel analysis attacks. 12 | 13 | Sensitive data remains in memory after AT91bootstrap hands control to application 14 | --------------------------------------------------------------------------------- 15 | 16 | One of the main tasks of the AT91bootstrap component is to authenticate and 17 | decrypt the next stage, for example, the U-Boot loader. For that, a set of 18 | hardcoded credentials is used, consisting of a key and an initialization 19 | vector (IV) for decryption as well as a CMAC key for authentication. 20 | 21 | It was found that these sensitive keys, which are part of AT91bootstrap image, 22 | are not completely wiped from memory after authentication and decryption is 23 | complete; only a copy located in stack variables is wiped [2], however the 24 | original values persist as part of the code segment. 25 | 26 | ``` 27 | int secure_decrypt(void *data, unsigned int data_length, int is_signed) 28 | { 29 | ... 30 | /* Init keys */ 31 | init_keys(&key_size, cipher_key, cmac_key, iv); 32 | 33 | /* Init periph */ 34 | at91_aes_init(); 35 | ... 36 | exit: 37 | /* Reset periph */ 38 | at91_aes_cleanup(); 39 | 40 | /* Reset keys */ 41 | memset(cmac_key, 0, sizeof(cmac_key)); 42 | memset(cipher_key, 0, sizeof(cipher_key)); 43 | memset(iv, 0, sizeof(iv)); 44 | 45 | return rc; 46 | ``` 47 | 48 | This allows the application to intercept these values when control is received 49 | from the bootstrap. 50 | 51 | To verify this finding, the bootstrap was built with recognizable keys (words 52 | with equal 4-bit nibbles set to incrementing value for each word). U-Boot was 53 | used as the application and configured to provide a command console. After the 54 | boot process was stopped, it was possible to dump memory where the bootstrap 55 | code is located, and with that, extract key material. The following abbreviated 56 | console capture shows how this was done. 57 | 58 | ``` 59 | RomBOOT 60 | Secure Boot Mode 61 | 62 | [ REMOVED FOR BREVITY ] 63 | AT91Bootstrap 3.8.10 (Fri Jan 31 04:59:36 UTC 2020) 64 | [ REMOVED FOR BREVITY ] 65 | U-Boot 2017.03-linux4sam_5.8 (Jan 26 2020 - 14:16:26 +0000) 66 | [ REMOVED FOR BREVITY ] 67 | Hit any key to stop autoboot: 0 68 | => md 00205150 14 69 | 00205150: aaaaaaaa 77777777 88888888 99999999 ....wwww........ 70 | 00205160: 11111111 33333333 44444444 dddddddd ....3333DDDD.... 71 | [REMOVED] 72 | ``` 73 | 74 | The key material can be recognized in the dumped data. Analysis showed the 75 | addresses belong to the code section; the address is provided directly in the 76 | example above for illustrative purposes. 77 | 78 | Impact 79 | ------ 80 | 81 | An attacker able to compromise the application stage, for example by forging 82 | the CMAC value as described below, gains access to cryptographic material used 83 | to encrypt and authenticate the application stage. This results in a 84 | compromise of the expected security guarantees and the ability to forge 85 | arbitrary applications. 86 | 87 | Timing side channel exists when verifying CMAC 88 | ---------------------------------------------- 89 | 90 | Apart from direct information leakage, for example, due to software disclosing 91 | sensitive data directly, it is possible to attack software using side channels 92 | which leak information indirectly. Timing side channel is one such kind which 93 | is caused due to time variations in certain algorithms depending on data being 94 | processed. 95 | 96 | The AT91boostrap code uses cipher-based message authentication code (CMAC) to 97 | authenticate the next stage before handing control over. By inspecting the 98 | source code, it was found that the AT91bootstrap loader employs such a 99 | time-varying operation in security critical code which verifies CMAC validity. 100 | This allows an attacker to dramatically speed up brute force attacks. 101 | 102 | The following code excerpt from the official source code tree [3] illustrates 103 | the issue: 104 | 105 | ``` 106 | int secure_decrypt(void *data, unsigned int data_length, int is_signed) 107 | { 108 | ... 109 | 110 | /* Check signature if required */ 111 | if (is_signed) { 112 | /* Compute the CMAC */ 113 | if (at91_aes_cmac(data_length, data, computed_cmac, 114 | key_size, cmac_key)) 115 | goto exit; 116 | 117 | /* Check the CMAC */ 118 | fixed_length = at91_aes_roundup(data_length); 119 | cmac = (const unsigned int *)((char *)data + fixed_length); 120 | if (memcmp(cmac, computed_cmac, AT91_AES_BLOCK_SIZE_BYTE)) 121 | goto exit; 122 | } 123 | ... 124 | ``` 125 | 126 | The memcmp() C library function does not provide any guarantee regarding its 127 | performance or fitness for cryptographic use, and its use in sensitive 128 | contexts is generally discouraged. The function's execution time strongly 129 | depends on how much data compares equal, allowing making precise guesses 130 | whether a given CMAC byte is correct or not. To provide an example, assume the 131 | attacker knows the first N bytes of a CMAC value for the given text; they take 132 | time measurements while trying all 256 values for the N+1'th byte. For the 133 | correct guess, execution time will be slightly longer; this value is accepted 134 | as correct and the procedure is repeated for the next byte. 135 | 136 | Impact 137 | ------ 138 | 139 | By timing the response, an attacker with physical access is able to conduct 140 | efficient attacks against the CMAC verification step and forge CMAC values for 141 | manipulated application images. While the images are encrypted, am attack may 142 | be conducted against AES-CBC by freely manipulating one block of encrypted 143 | data using XOR. 144 | 145 | Affected versions 146 | ----------------- 147 | 148 | The issues were identified in AT91bootstrap version 3.9.1. Prior versions may 149 | also be affected. 150 | 151 | Solution 152 | -------- 153 | 154 | Update to version 3.9.2 when available or apply patches provided by the vendor. 155 | 156 | CVE assignment 157 | -------------- 158 | 159 | The issues were assigned CVE-2020-11683 and CVE-2020-11684 correspondingly. 160 | 161 | Credit 162 | ------ 163 | 164 | The issues were discovered by Dmitry Janushkevich of F-Secure Hardware Security team. 165 | 166 | Detailed timeline 167 | ----------------- 168 | 169 | Date | Summary 170 | -----------|--------- 171 | 2020-02-07 | First contact 172 | 2020-02-07 | Details provided to Microchip 173 | 2020-02-25 | F-Secure requests status update 174 | 2020-02-27 | Microchip informs of fixes being prepared for the next software release. 175 | 2020-03-30 | Without notifying F-Secure, Microchip publishes the patches 176 | 2020-03-31 | Microchip provides the patches for review 177 | 2020-04-06 | F-Secure discovers the patches are public 178 | 2020-04-10 | CVEs assigned by MITRE 179 | 2020-04-20 | Public release 180 | 181 | References 182 | ---------- 183 | 184 | 1. https://github.com/linux4sam/at91bootstrap 185 | 2. https://github.com/linux4sam/at91bootstrap/blob/v3.9.1/driver/secure.c#L116 186 | 3. https://github.com/linux4sam/at91bootstrap/blob/v3.9.1/driver/secure.c#L106 187 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_FSC-HWSEC-VR2020-0003-ATSAMA5_code_authentication_issues.txt: -------------------------------------------------------------------------------- 1 | Microchip ATSAMA5 SoC Multiple Vulnerabilities 2 | ============================================== 3 | 4 | Multiple vulnerabilities have been discovered which affect the security of solutions 5 | built using the Microchip ATSAMA5 SoC series, when making use of the Secure Boot 6 | capabilities of these SoCs. This pre-release advisory describes the identified 7 | vulnerable situations and affected part numbers while trying to limit exposure for 8 | products integrating these SoCs. The full technical advisory will be released in 9 | the near future. 10 | 11 | 12 | Improper applet handling 13 | ------------------------ 14 | 15 | A programming error was discovered which allows an attacker to bypass existing 16 | security mechanisms related to applet handling when the attacked device is in 17 | Secure Mode. 18 | 19 | This only affects products which have Secure Monitor enabled. 20 | 21 | 22 | CMAC verification susceptible to SPA 23 | ------------------------------------ 24 | 25 | The AES-128 based CMAC authentication is used to prove authenticity and integrity 26 | of software components such as monitor applets and bootstrap code. The implementation 27 | of CMAC verification functionality was found to be vulnerable to timing and power 28 | analysis attacks. 29 | 30 | 31 | Hardcoded keys are used for protecting applets 32 | ---------------------------------------------- 33 | 34 | It was found that the key set used to encrypt and authenticate secure applets is 35 | hardcoded within the Secure Monitor and is available for abuse once this code has 36 | been extracted. 37 | 38 | This only affects products which have Secure Monitor enabled. 39 | 40 | 41 | Impact 42 | ------ 43 | 44 | The cumulative impact of the described issues leads to a significant compromise of 45 | the expected security guarantees provided by the Secure Boot feature when no 46 | mitigations are applied. 47 | 48 | 49 | Affected part numbers 50 | --------------------- 51 | 52 | Affected CPNs for the SAMA5D2 product line: 53 | 54 | * ATSAMA5D21C-CU, ATSAMA5D21C-CUR 55 | * ATSAMA5D22C-CN, ATSAMA5D22C-CNR, ATSAMA5D22C-CU, ATSAMA5D22C-CUR 56 | * ATSAMA5D23C-CN, ATSAMA5D23C-CNR, ATSAMA5D23C-CU, ATSAMA5D23C-CUR 57 | * ATSAMA5D24C-CU, ATSAMA5D24C-CUF, ATSAMA5D24C-CUR 58 | * ATSAMA5D26C-CN, ATSAMA5D26C-CNR, ATSAMA5D26C-CU, ATSAMA5D26C-CUR 59 | * ATSAMA5D27C-CN, ATSAMA5D27C-CNR, ATSAMA5D27C-CU, ATSAMA5D27C-CUR 60 | * ATSAMA5D28C-CN, ATSAMA5D28C-CNR, ATSAMA5D28C-CU, ATSAMA5D28C-CUR 61 | * ATSAMA5D27C-CNVAO, ATSAMA5D27C-CNRVAO 62 | 63 | SiP variants: 64 | 65 | * ATSAMA5D225C-D1M-CUR 66 | * ATSAMA5D27C-D5M-CU, ATSAMA5D27C-D5M-CUR, 67 | * ATSAMA5D27C-D1G-CU, ATSAMA5D27C-D1G-CUR 68 | * ATSAMA5D28C-D1G-CU, ATSAMA5D28C-D1G-CUR 69 | * ATSAMA5D27C-LD1G-CU, ATSAMA5D27C-LD1G-CUR 70 | * ATSAMA5D27C-LD2G-CU, ATSAMA5D27C-LD2G-CUR 71 | * ATSAMA5D28C-LD1G-CU, ATSAMA5D28C-LD1G-CUR 72 | * ATSAMA5D28C-LD2G-CU, ATSAMA5D28C-LD2G-CUR 73 | 74 | SoM variants: 75 | 76 | * ATSAMA5D27-WLSOM1 77 | * ATSAMA5D27-SOM1 78 | 79 | Affected CPNs for the SAMA5D3 product line: 80 | 81 | * ATSAMA5D31A-CU, ATSAMA5D31A-CUR, ATSAMA5D31A-CFU, ATSAMA5D31A-CFUR 82 | * ATSAMA5D33A-CU, ATSAMA5D33A-CUR 83 | * ATSAMA5D34A-CU, ATSAMA5D34A-CUR 84 | * ATSAMA5D35A-CU, ATSAMA5D35A-CUR, ATSAMA5D35A-CN, ATSAMA5D35A-CNR 85 | * ATSAMA5D36A-CU, ATSAMA5D36A-CUR, ATSAMA5D36A-CN, ATSAMA5D36A-CNR 86 | 87 | Affected CPNs for the SAMA5D4 product line: 88 | 89 | * ATSAMA5D41A-CU, ATSAMA5D41A-CUR, ATSAMA5D41B-CU, ATSAMA5D41B-CUR 90 | * ATSAMA5D42A-CU, ATSAMA5D42A-CUR, ATSAMA5D42B-CU, ATSAMA5D42B-CUR 91 | * ATSAMA5D43A-CU, ATSAMA5D43A-CUR, ATSAMA5D43B-CU, ATSAMA5D43B-CUR 92 | * ATSAMA5D44A-CU, ATSAMA5D44A-CUR, ATSAMA5D44B-CU, ATSAMA5D44B-CUR 93 | 94 | 95 | Solution 96 | -------- 97 | 98 | For products based on the SAMA5D2 and SAMA5D4 devices, disabling the SAM-BA monitor 99 | after provisioning the chips mitigates all the reported issues. This can be done by 100 | setting the "Disable Monitor" bit in the fuse area. 101 | 102 | CMAC verification issue may be mitigated by choosing the RSA authentication option to 103 | replace CMAC calculation. 104 | 105 | For products based on the SAMA5D3 devices, no mitigations were identified. The only 106 | identified solution is to update the products to the next silicon revision when made 107 | available by Microchip. 108 | 109 | 110 | CVE assignment 111 | -------------- 112 | 113 | CVE | Issue 114 | ---------------|------- 115 | CVE-2020-12787 | Improper applet verification 116 | CVE-2020-12788 | CMAC verification susceptible to SPA 117 | CVE-2020-12789 | Hardcoded keys are used for protecting applets 118 | 119 | 120 | Credit 121 | ------ 122 | 123 | The issues were discovered by Dmitry Janushkevich of F-Secure Hardware Security team. 124 | 125 | 126 | Detailed timeline 127 | ----------------- 128 | 129 | YYYY-MM-DD | Event 130 | -----------|------ 131 | 2020-01-23 | Initial contact. Details and suggested mitigations provided to Microchip, 132 | as well as proposing a 90 days disclosure timeline. 133 | 2020-01-24 | Microchip confirms the reception. 134 | 2020-01-28 | Microchip informs they are in the process of confirming the issues. 135 | 2020-02-04 | F-Secure requests a status update. 136 | 2020-02-05 | Microchip provides a status update and confirms the issues against 137 | SAMA5D27. Microchip intends to respond "in few days" regarding the 138 | disclosure timeline. 139 | 2020-02-25 | F-Secure requests a status update. 140 | 2020-02-27 | Microchip informs they are still working on identifying mitigations. 141 | 2020-03-17 | F-Secure requests a status update. 142 | 2020-03-19 | Microchip confirms SAMA5D3 and SAMA5D4 are also vulnerable, as well as 143 | informing F-Secure that suggested mitigations may not be applicable for 144 | all devices. Microchip starts planning a disclosure toward the customers. 145 | 2020-04-20 | F-Secure informs Microchip about the embargo period expiring. 146 | 2020-04-23 | 90 day disclosure deadline missed. 147 | 2020-04-28 | Microchip informs regarding the mitigation plan for SAMA5D3. Microchip 148 | requests postponing the disclosure until December 2020 or early 2021. 149 | 2020-04-28 | F-Secure suggests timing the disclosure to the planned customer 150 | communication activities as information will become effectively public 151 | despite the limited amount of people being informed. 152 | 2020-05-04 | Conference call between Microchip and F-Secure. An agreement is reached 153 | for limited (what is vulnerable, impact) disclosure within weeks and 154 | full disclosure upon fixed part availability. 155 | 2020-05-09 | Microchip provides a draft of planned customer communication document. 156 | Also included is the list of affected part numbers for the D2 series. 157 | 2020-05-11 | F-Secure requests CVE identifiers from MITRE. 158 | 2020-05-12 | F-Secure provides a draft of planned limited disclosure document together 159 | with feedback on the Microchip document. 160 | 2020-05-19 | Microchip responds regarding the level of detail provided. 161 | 2020-05-21 | F-Secure provides a second draft of planned limited disclosure document 162 | with bare minimum of information included. 163 | 2020-05-25 | Tentative deadline for limited disclosure missed. 164 | 2020-05-30 | Microchip responds regarding the level of detail provided. Microchip also 165 | informs about starting the dissemination of limited information among 166 | select customers. 167 | 2020-05-30 | Microchip provides the list of affected part numbers for the D3 and D4 series. 168 | 2020-06-04 | F-Secure informs the vendor on the decision to adhere to the previously 169 | discussed limited disclosure, setting the new deadline to 2020-06-10. 170 | 2020-06-10 | Limited disclosure document published. 171 | 172 | 173 | References 174 | ---------- 175 | 176 | References will be provided upon availability from Microchip. 177 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_FSC-HWSEC-VR2021-0001-OP-TEE_TrustZone_bypass.txt: -------------------------------------------------------------------------------- 1 | Security advisory: OP-TEE TrustZone bypass on multiple NXP i.MX models 2 | ====================================================================== 3 | 4 | The Open Portable Trusted Execution Environment (OP-TEE) [1] is an open source 5 | Trusted Execution Environment (TEE) implementing the Arm TrustZone technology. 6 | 7 | F-Secure Foundry, in the process of developing its own TEE framework (GoTEE 8 | [2]), reviewed the existing Open Source offering and identified a vulnerability 9 | in OP-TEE support for the Central Security Unit (CSU) configuration of several 10 | NXP i.MX System-on-Chip (SoC) part numbers (P/Ns). 11 | 12 | Based on these findings F-Secure advises OP-TEE users to treat all OP-TEE 13 | supported platforms as insecure by default and carefully review their 14 | implementation before integration. 15 | 16 | TrustZone configuration on i.MX SoCs 17 | ------------------------------------ 18 | 19 | The following GoTEE tutorial [3] provides an in-depth explanation of the 20 | various aspects of an effective TrustZone configuration. 21 | 22 | In a nutshell, along with standard ARM core configuration, each SoC requires 23 | its peripherals to be assigned to either the Secure World or Normal World (aka 24 | NonSecure World), which respectively represent the privileged and unprivileged 25 | TrustZone domains. 26 | 27 | When granting Normal World access to a specific peripheral it is essential to 28 | flag such peripheral as NonSecure, as the permissions for accessing peripherals 29 | are different than their privilege level. 30 | 31 | In other words if NonSecure World is granted access to a peripheral that can 32 | perform arbitrary memory read/write operations, it is vital to flag that 33 | peripheral as a NonSecure bus controller. 34 | 35 | Failure to do so results in a TrustZone bypass as the NonSecure World can 36 | simply use the peripherals to read/write Secure World memory. 37 | 38 | On the NXP i.MX family several peripherals can independently perform DMA, the 39 | prime example is the Smart Direct Memory Access (SDMA) controller. Another 40 | example would be the Ethernet controller (FEC/ENET) as it can be configured 41 | with arbitrary memory pointers for transmit/receive ring buffer location. 42 | 43 | The Central Security Unit (CSU) is the component that enables TrustZone 44 | peripheral configuration, on the NXP i.MX family, for all peripherals that are 45 | not capable of asserting TrustZone signals independently. 46 | 47 | The CSU Config Security Level (CSL) defines restrictions for accessing 48 | individual (or groups of) peripherals (e.g. whether a peripheral can be 49 | accessed from NonSecure World) while the Security Access (SA) defines their 50 | access security policy (e.g. whether a peripheral makes bus accesses as Secure 51 | or NonSecure). 52 | 53 | Vulnerability (CVE-2021-36133) 54 | ------------------------------ 55 | 56 | The OP-TEE OS CSU driver [4] sets a CSL which grants NonSecure access to most 57 | i.MX peripherals, with the exception of security sensitive ones such as the ROM 58 | patching controller (ROMCP) or the DCP cryptographic co-processor. 59 | 60 | However the SA is never set for several i.MX6 variants as well as the i.MX7, 61 | causing the CSU default Secure World access privilege to be applied. 62 | 63 | Additionally OP-TEE returns CSU initialization success on all SoC P/Ns which do 64 | not have an explicit configuration, a dangerous patterns which extends the 65 | vulnerability to the additional i.MX8 targets enabled on NXP own OP-TEE fork 66 | [5], as they do not have a specific CSU configuration. 67 | 68 | Vulnerability (CVE-2021-44149) 69 | ------------------------------ 70 | 71 | The OP-TEE OS CSU driver [4] sets an SA for the NXP i.MX6UL P/N, however this 72 | SA is affected by additional vulnerabilities, see the separate advisories ([8] 73 | and [9]) for further information. 74 | 75 | Impact 76 | ------ 77 | 78 | On vanilla OP-TEE OS the NXP i.MX6 and its UL/ULL/ULZ, SL/SLL, SX variants as 79 | well as all NXP i.MX7 variants have no effective TrustZone isolation as the 80 | Normal World can arbitrarily read/write Secure World memory, resulting in a 81 | full compromise of the Trusted Execution Environment. 82 | 83 | On NXP OP-TEE fork [5], the same vulnerability applies but its scope is 84 | extended to the additional supported for the i.MX8 SoC family. 85 | 86 | Vendor response 87 | --------------- 88 | 89 | On June 30th the OP-TEE projects communicated their assessment of the reported 90 | issue to a severity rating of "low", with the reasoning copied in verbatim 91 | below. 92 | 93 | F-Secure believes that the OP-TEE should either provide an explicitly "open" 94 | configuration, with clear documentation notices, or working protection for 95 | Secure World assigned peripherals. 96 | 97 | The official platform support for the findings in scope instead includes an 98 | inconsistent configuration which gives the illusion of protection (per [4] own 99 | comments) without it being effective. 100 | 101 | F-Secure advises OP-TEE users to treat all OP-TEE supported platforms as 102 | insecure by default and carefully review their implementation before 103 | integration. 104 | 105 | The following quote is the verbatim response from the OP-TEE project: 106 | 107 | "After further discussions and in agreement with NXP we've decided to 108 | downgrade this from a severity high to low (an informative issue), which 109 | means that it'll not be treated as a security vulnerability. The reasons 110 | are as stated by NXP below. 111 | 112 | We have similar standpoints in the OP-TEE project where we for example have 113 | added a disclaimer to the Raspberry Pi section [1] and as another example we 114 | have a "porting guidelines" [2] where we mentioned that the HUK is stubbed and 115 | that the Trusted Application RSA keys are just example keys that needs to be 116 | replaced by the one intending to make a secure product. I.e., for open source 117 | projects working as reference builds there are in some cases configurations 118 | that are needed to make a final product secure, but cannot be enabled for 119 | various reasons in the reference build. 120 | 121 | As mentioned by NXP, they will submit a documentation patch to the OP-TEE 122 | project that adds a similar section for NXP devices that clarifies this. 123 | 124 | Trusted Stakeholders to the OP-TEE project have already been notified once and 125 | they will receive an additional update containing the same information as 126 | you've received here. 127 | 128 | [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html 129 | [2] https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html 130 | 131 | NXP statements: 132 | 133 | - NXP acknowledges the fact that going into production with the default i.MX 134 | CSU configuration in OP-TEE represents a security issue. 135 | 136 | - However NXP is not responsible for the security configuration of OP-TEE : 137 | it’s up to the customer/developer to lock and secure the platforms according 138 | to their specific needs. 139 | 140 | - NXP cannot provide a secure configuration for OP-TEE that fits all customer 141 | needs : that’s why by default, the i.MX security in OP-TEE OS is open. Trying 142 | to satisfy all security needs for all different possible configurations at the 143 | same time is not doable. 144 | 145 | - The CSU documentation and steps to configure it properly is available in the 146 | i.MX Reference Manual. 147 | 148 | - NXP does not deliver OP-TEE OS as a product but as enablement software. NXP 149 | does not implement security but NXP provides tools and software for the 150 | customer to implement security. 151 | 152 | - NXP will publish a NXP/i.MX dedicated section in the OP-TEE documentation 153 | where a disclaimer will warn about this default open security configuration 154 | of i.MX platforms. 155 | " 156 | 157 | It should be noted that NXP statement on CSU documentation is incorrect and 158 | that "i.MX Reference Manual" should read "i.MX Security Reference Manual" 159 | (typically available under EULA/NDA). 160 | 161 | The OP-TEE project released their own advisory in relation to F-Secure report 162 | [7]. 163 | 164 | Affected versions 165 | ----------------- 166 | 167 | The OP-TEE OS component of all OP-TEE releases supporting NXP i.MX P/Ns are 168 | vulnerable, this includes any fork (such as the NXP one [5]) based on them. 169 | 170 | Credit 171 | ------ 172 | 173 | Vulnerabilities discovered and reported by Andrea Barisani and Andrej Rosano 174 | (F-Secure Foundry [6]). 175 | 176 | CVE 177 | --- 178 | 179 | CVE-2021-36133: OP-TEE TrustZone bypass on multiple NXP i.MX models 180 | 181 | Timeline 182 | -------- 183 | 184 | 2021-06-07: findings reported by F-Secure to OP-TEE security contact. 185 | 2021-06-10: OP-TEE confirms the findings, requests 90 days embargo. 186 | 2021-06-10: OP-TEE communicates that NXP ranks the findings as high severity. 187 | 2021-06-11: F-Secure requests 30 days embargo. 188 | 2021-06-30: OP-TEE downgrades the findings severity from high to low. 189 | 2021-07-02: F-Secure receives CVE-2021-36133 assignment from MITRE. 190 | 2021-07-12: advisory release. 191 | 2021-07-13: added OP-TEE advisory link. 192 | 2021-11-22: added reference to CVE-2021-44149 advisory. 193 | 194 | References 195 | ---------- 196 | 197 | [1] https://www.op-tee.org/ 198 | [2] https://github.com/f-secure-foundry/GoTEE 199 | [3] https://github.com/f-secure-foundry/GoTEE/wiki/TrustZone-configuration 200 | [4] https://github.com/OP-TEE/optee_os/blob/3.13.0/core/arch/arm/plat-imx/drivers/imx_csu.c 201 | [5] https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/arch/arm/plat-imx/drivers/imx_csu.c?h=imx_5.4.70_2.3.0 202 | [6] https://foundry.f-secure.com 203 | [7] https://github.com/OP-TEE/optee_os/security/advisories/GHSA-6q85-3ph3-rm47 204 | [8] https://github.com/f-secure-foundry/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2021-0002-OP-TEE_TrustZone_bypass.txt 205 | [9] https://github.com/OP-TEE/optee_os/security/advisories/GHSA-4pqr-q8rf-8464 206 | 207 | Permalink 208 | --------- 209 | 210 | https://github.com/f-secure-foundry/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2021-0001-OP-TEE_TrustZone_bypass.txt 211 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_FSC-HWSEC-VR2021-0002-OP-TEE_TrustZone_bypass_at_wakeup.txt: -------------------------------------------------------------------------------- 1 | Security advisory: OP-TEE TrustZone bypass at wakeup on NXP i.MX6UL 2 | =================================================================== 3 | 4 | The Open Portable Trusted Execution Environment (OP-TEE) [1] is an open source 5 | Trusted Execution Environment (TEE) implementing the Arm TrustZone technology. 6 | 7 | F-Secure Foundry, in the process of developing its own TEE framework (GoTEE 8 | [2]), reviewed the existing Open Source offering and identified a vulnerability 9 | in OP-TEE support for the Central Security Unit (CSU) configuration on the NXP 10 | i.MX6UL System-on-Chip (SoC). 11 | 12 | Based on this, as well as previous [7] findings, F-Secure advises OP-TEE users 13 | to treat all OP-TEE supported platforms as insecure by default and carefully 14 | review and practically test their implementation before integration. 15 | 16 | TrustZone configuration on i.MX SoCs 17 | ------------------------------------ 18 | 19 | The following GoTEE tutorial [3] provides an in-depth explanation of the 20 | various aspects of an effective TrustZone configuration. 21 | 22 | In a nutshell, along with standard ARM core configuration, each SoC requires 23 | its peripherals to be assigned to either the Secure World or Normal World (aka 24 | NonSecure World), which respectively represent the privileged and unprivileged 25 | TrustZone domains. 26 | 27 | The Central Security Unit (CSU) is the component that enables TrustZone 28 | peripheral configuration on the NXP i.MX family for peripherals that are 29 | not capable of asserting TrustZone signals independently. 30 | 31 | The CSU Config Security Level (CSL) defines restrictions for accessing 32 | individual (or groups of) peripherals (e.g. whether a peripheral can be 33 | accessed from NonSecure World) while the Security Access (SA) defines the 34 | access security policy for the peripheral (e.g. whether the peripheral 35 | makes bus accesses as "Secure" or "NonSecure"). 36 | 37 | Vulnerability (CVE-2021-44149) 38 | ------------------------------ 39 | 40 | The OP-TEE OS CSU driver [4] sets the CSU Security Access (SA) policy for the 41 | ARM Cortex-A7 block (CA7) to "Secure" for its NXP i.MX6UL SoC support. 42 | 43 | The NXP documentation on the role of the CA7 SA setting does not provide any 44 | details on its effects, therefore F-Secure conducted a thorough analysis of its 45 | manipulation, which resulted in identification of a vulnerability. 46 | 47 | It has been verified that the OP-TEE configuration allows a processor suspended 48 | in Normal World security state to wake up from low power mode in Secure World 49 | state. 50 | 51 | The wakeup sequence implemented in the NXP i.MX6UL boot ROM jumps, in secure 52 | processor state, to function pointers held in the System Reset Controller (SRC) 53 | registers. The vulnerability takes place when the Normal World OS is allowed to 54 | set the SRC wakeup pointers before going in low power mode. 55 | 56 | For example when running Linux under OP-TEE OS the boot ROM executes a wakeup 57 | handler previously configured by Normal World Linux, within Secure World. This 58 | results in Linux re-initializing the MMU and resuming all its execution context 59 | as Secure World. 60 | 61 | This configuration effectively bypasses any intended TrustZone protection as 62 | the Normal World OS is capable of transforming itself, through a low power 63 | suspend/wakeup procedure, to a Secure one. 64 | 65 | It should be highlighted that the boot ROM unconditionally wakes up in secure 66 | processor state. The CA7 SA only affects the CP15SDISABLE input signal which, 67 | when set as "NonSecure", causes a fault in the boot ROM code, even if running 68 | in Secure World, as it becomes incapable of accessing specific secure registers 69 | needed by its wake up flow. 70 | 71 | Impact 72 | ------ 73 | 74 | On vanilla OP-TEE OS the NXP i.MX6UL SoC has no effective TrustZone isolation 75 | as the Normal World can arbitrarily change its processor state to Secure World, 76 | resulting in a full compromise of the Trusted Execution Environment. 77 | 78 | The same vulnerability also applies to the NXP OP-TEE fork [5]. 79 | 80 | Mitigation 81 | ---------- 82 | 83 | Any suspend/wakeup functionality must be handled by the Secure World TEE as the 84 | CSU Config Security Level (CSL) must be set to protect, from Normal World 85 | access, all blocks responsible for the wakeup sequence such as the GPC and SRC 86 | blocks on the i.MX6UL SoC family. 87 | 88 | When suspend/wakeup functionality is not required, implementers of trusted 89 | firmware using the OP-TEE framework can re-configure the SA policy ensuring 90 | that the CA7 value is set as "NonSecure" prior to Normal World execution. 91 | 92 | When running Linux in Normal World this is incompatible with Linux power 93 | management drivers which require SRC support on i.MX6 SoCs (example: 94 | `CONFIG_CPU_IDLE`). 95 | 96 | It is emphasized that changing the CA7 SA policy bit to "NonSecure", while 97 | effective, represents a weaker form of mitigation as the exploitation of the 98 | vulnerability is only incidentally prevented, the proper mitigation remains the 99 | CSL protection for the responsible GPC and SRC blocks. 100 | 101 | Please also note that such mitigations do not constitute an example of a fully 102 | secure configuration and only focus on the specific aspects reported in this 103 | advisory. 104 | 105 | Vendor response 106 | --------------- 107 | 108 | The OP-TEE project own security advisory can be found at [8]. 109 | 110 | Affected versions 111 | ----------------- 112 | 113 | The OP-TEE OS component of all OP-TEE releases supporting the NXP i.MX6UL SoC 114 | is vulnerable, this includes any fork (such as the NXP one [5]) based on them 115 | that does not correctly prevent Normal World control of the System Reset 116 | Controller (SRC) wakeup execution context. 117 | 118 | Please be advised that OP-TEE does not provide a secure CSU configuration on 119 | multiple NXP i.MX P/Ns for reasons which go beyond this specific finding (see 120 | CVE-2021-36133 [7]). 121 | 122 | Credit 123 | ------ 124 | 125 | Vulnerabilities discovered and reported by Andrea Barisani and Andrej Rosano 126 | (F-Secure Foundry [6]). 127 | 128 | CVE 129 | --- 130 | 131 | CVE-2021-44149: OP-TEE TrustZone bypass at wakeup on NXP i.MX6UL 132 | 133 | Timeline 134 | -------- 135 | 136 | 2021-11-05: findings reported by F-Secure to OP-TEE security contact. 137 | 2021-11-05: F-Secure requests 14 days embargo. 138 | 2021-11-18: OP-TEE requests 30 days embargo. 139 | 2021-11-18: OP-TEE and NXP confirms the finding. 140 | 2021-11-18: OP-TEE confirms no mitigation will be applied, only improved docs. 141 | 2021-11-18: F-Secure confirms initial 14 days embargo. 142 | 2021-11-22: F-Secure receives CVE-2021-44149 assignment from MITRE. 143 | 2021-11-22: advisory release. 144 | 2021-12-15: NXP clarifies CA7 SA affecting only CP15SDISABLE, update mitigation. 145 | 146 | References 147 | ---------- 148 | 149 | [1] https://www.op-tee.org/ 150 | [2] https://github.com/f-secure-foundry/GoTEE 151 | [3] https://github.com/f-secure-foundry/GoTEE/wiki/TrustZone-configuration 152 | [4] https://github.com/OP-TEE/optee_os/blob/3.15.0/core/arch/arm/plat-imx/drivers/imx_csu.c 153 | [5] https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/arch/arm/plat-imx/drivers/imx_csu.c?h=lf-5.10.52_2.1.0 154 | [6] https://foundry.f-secure.com 155 | [7] https://github.com/f-secure-foundry/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2021-0001-OP-TEE_TrustZone_bypass.txt 156 | [8] https://github.com/OP-TEE/optee_os/security/advisories/GHSA-4pqr-q8rf-8464 157 | 158 | Permalink 159 | --------- 160 | 161 | https://github.com/f-secure-foundry/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2021-0002-OP-TEE_TrustZone_bypass_at_wakeup.txt 162 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_GLSA200312-03-rsync_heap_overflow.txt: -------------------------------------------------------------------------------- 1 | rsync 2.5.6 security advisory 2 | ----------------------------- 3 | 4 | December 4th 2003 5 | 6 | 7 | Background 8 | ---------- 9 | 10 | The rsync team has received evidence that a vulnerability in rsync was 11 | recently used in combination with a Linux kernel vulnerability to 12 | compromise the security of a public rsync server. While the forensic 13 | evidence we have is incomplete, we have pieced together the most 14 | likely way that this attack was conducted and we are releasing this 15 | advisory as a result of our investigations to date. 16 | 17 | Our conclusions are that: 18 | 19 | - rsync version 2.5.6 contains a heap overflow vulnerability that can 20 | be used to remotely run arbitrary code. 21 | 22 | - While this heap overflow vulnerability could not be used by itself 23 | to obtain root access on a rsync server, it could be used in 24 | combination with the recently announced brk vulnerability in the 25 | Linux kernel to produce a full remote compromise. 26 | 27 | - The server that was compromised was using a non-default rsyncd.conf 28 | option "use chroot = no". The use of this option made the attack on 29 | the compromised server considerably easier. A successful attack is 30 | almost certainly still possible without this option, but it would 31 | be much more difficult. 32 | 33 | Please note that this vulnerability only affects the use of rsync as a 34 | "rsync server". To see if you are running a rsync server you should 35 | use the netstat command to see if you are listening on TCP port 36 | 873. If you are not listening on TCP port 873 then you are not running 37 | a rsync server. 38 | 39 | 40 | New rsync release 41 | ----------------- 42 | 43 | In response we have released a new version of rsync, version 44 | 2.5.7. This is based on the current stable 2.5.6 release with only the 45 | changes necessary to prevent this heap overflow vulnerability. There 46 | are no new features in this release. 47 | 48 | We recommend that anyone running a rsync server take the following 49 | steps: 50 | 51 | 1) update to rsync version 2.5.7 immediately 52 | 53 | 2) if you are running a Linux kernel prior to version 2.4.23 then 54 | you should upgrade your kernel immediately. Note that some 55 | distribution vendors may have patched versions of the 2.4.x 56 | series kernel that fix the brk vulnerability in versions before 57 | 2.4.23. Check with your vendor security site to ensure that you 58 | are not vulnerable to the brk problem. 59 | 60 | 3) review your /etc/rsyncd.conf configuration file. If you are 61 | using the option "use chroot = no" then remove that line or 62 | change it to "use chroot = yes". If you find that you need that 63 | option for your rsync service then you should disable your rsync 64 | service until you have discussed a workaround with the rsync 65 | maintainers on the rsync mailing list. The disabling of the 66 | chroot option should not be needed for any normal rsync server. 67 | 68 | The patches and full source for rsync version 2.5.7 are available from 69 | http://rsync.samba.org/ and mirror sites. We expect that vendors will 70 | produce updated packages for their distributions shortly. 71 | 72 | 73 | Credits 74 | ------- 75 | 76 | The rsync team would like to thank the following individuals for their 77 | assistance in investigating this vulnerability and producing this 78 | response: 79 | 80 | * Timo Sirainen 81 | 82 | * Mike Warfield 83 | 84 | * Paul Russell 85 | 86 | * Andrea Barisani 87 | 88 | Regards, 89 | 90 | The rsync team 91 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_GLSA200604-10-zgv_heap_overflow.txt: -------------------------------------------------------------------------------- 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2 | Gentoo Linux Security Advisory GLSA 200604-10 3 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4 | http://security.gentoo.org/ 5 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6 | 7 | Severity: Normal 8 | Title: zgv, xzgv: Heap overflow 9 | Date: April 21, 2006 10 | Bugs: #127008 11 | ID: 200604-10 12 | 13 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 14 | 15 | Synopsis 16 | ======== 17 | 18 | xzgv and zgv attempt to decode JPEG images within the CMYK/YCCK colour 19 | space incorrectly, potentially resulting in the execution of arbitrary 20 | code. 21 | 22 | Background 23 | ========== 24 | 25 | xzgv and zgv are picture viewing utilities with a thumbnail based file 26 | selector. 27 | 28 | Affected packages 29 | ================= 30 | 31 | ------------------------------------------------------------------- 32 | Package / Vulnerable / Unaffected 33 | ------------------------------------------------------------------- 34 | 1 media-gfx/xzgv < 0.8-r2 >= 0.8-r2 35 | 2 media-gfx/zgv < 5.8 >= 5.8 36 | ------------------------------------------------------------------- 37 | 2 affected packages on all of their supported architectures. 38 | ------------------------------------------------------------------- 39 | 40 | Description 41 | =========== 42 | 43 | Andrea Barisani of Gentoo Linux discovered xzgv and zgv allocate 44 | insufficient memory when rendering images with more than 3 output 45 | components, such as images using the YCCK or CMYK colour space. When 46 | xzgv or zgv attempt to render the image, data from the image overruns a 47 | heap allocated buffer. 48 | 49 | Impact 50 | ====== 51 | 52 | An attacker may be able to construct a malicious image that executes 53 | arbitrary code with the permissions of the xzgv or zgv user when 54 | attempting to render the image. 55 | 56 | Workaround 57 | ========== 58 | 59 | There is no known workaround at this time. 60 | 61 | Resolution 62 | ========== 63 | 64 | All xzgv users should upgrade to the latest version: 65 | 66 | # emerge --sync 67 | # emerge --ask --oneshot --verbose ">=media-gfx/xzgv-0.8-r2" 68 | 69 | All zgv users should also upgrade to the latest version: 70 | 71 | # emerge --sync 72 | # emerge --ask --oneshot --verbose ">=media-gfx/zgv-5.8" 73 | 74 | References 75 | ========== 76 | 77 | [ 1 ] CVE-2006-1060 78 | http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1060 79 | 80 | Availability 81 | ============ 82 | 83 | This GLSA and any updates to it are available for viewing at 84 | the Gentoo Security Website: 85 | 86 | http://security.gentoo.org/glsa/glsa-200604-10.xml 87 | 88 | License 89 | ======= 90 | 91 | Copyright 2006 Gentoo Foundation, Inc; referenced text 92 | belongs to its owner(s). 93 | 94 | The contents of this document are licensed under the 95 | Creative Commons - Attribution / Share Alike license. 96 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_IPVR2016-0001_AppleUSBNetworking_memory_corruption.txt: -------------------------------------------------------------------------------- 1 | CVE-2016-1734 - AppleUSBNetworking memory corruption 2 | 3 | Inverse Path (https://www.inversepath.com) identified a potential security 4 | vulnerability in the way OS X handles RNDIS/Ethernet gadgets USB devices, 5 | advertising invalid USB descriptor information. 6 | 7 | The RNDIS driver is commonly used for emulating Ethernet TCP/IP connectivity 8 | on USB devices such as mobile phones or custom boards such as our USB armory 9 | (https://github.com/f-secure-foundry/usbarmory). 10 | 11 | While testing descriptor manipulation we found that a high-speed USB device, 12 | advertising specific descriptors which match full-speed values, caused the OS 13 | X instance to immediately panic and reboot once the device is plugged in and 14 | network traffic is generated from the device. This happens regardless of a 15 | user being logged in or not. 16 | 17 | The test scenario involves USB descriptors, for a high-speed USB device, 18 | configured with the following invalid values: 19 | 20 | bInterval set to 32 in the Interrupt type Endpoint Descriptors 21 | wMaxPacketSize set to 1 x 64 bytes in the Bulk type Endpoint Descriptors 22 | 23 | These values are incorrect as normally bInterval is 9 and wMaxPacketSize is 24 | 512 bytes on high-speed devices. 25 | 26 | The resulting panic report (which is sometimes, and not all times, generated) 27 | is as follows: 28 | 29 | *** Panic Report *** 30 | panic(cpu 0 caller 0xffffff8005f6bc0c): Failed mbuf validity check: mbuf 31 | 0xffffff809ac55400 len -8 type 1 flags 0x2 data 0xffffff809ac554b8 rcvif en8 32 | ifflags 0x8863 33 | Backtrace (CPU 0), Frame : Return Address 34 | 0xffffff809f60be20 : 0xffffff8005ce5307 35 | 0xffffff809f60bea0 : 0xffffff8005f6bc0c 36 | 0xffffff809f60bf60 : 0xffffff8005f6e819 37 | 0xffffff809f60bfb0 : 0xffffff8005dd15d7 38 | 39 | The issue has been tested on OS X 10.11.1 (build version 15b42) using a 40 | MacBook Pro mid-2012 (Model A1278). 41 | 42 | The panic is triggered by network traffic being exchanged over the interface 43 | and not just the mere USB enumeration, therefore it seems that the invalid 44 | descriptors are negatively affecting the way Ethernet traffic is being parsed 45 | on OS X. 46 | 47 | A single packet, reproducing the scenario, has been identified to consistently 48 | trigger the crash. 49 | 50 | 01:02:03.719455 Out 1a:55:89:a2:69:51 ethertype IPv6 (0x86dd), length 72: 51 | (hlim 255, next-header ICMPv6 (58) payload length: 16) 52 | fe80::1855:89ff:fea2:6951 > ff02::2: [icmp6 sum ok] ICMP6, router 53 | solicitation, length 16 54 | 55 | source link-address option (1), length 8 (1): 1a:55:89:a2:69:51 56 | 0x0000: 6000 0000 0010 3aff fe80 0000 0000 0000 `.....:......... 57 | 0x0010: 1855 89ff fea2 6951 ff02 0000 0000 0000 .U....iQ........ 58 | 0x0020: 0000 0000 0000 0002 8500 649c 0000 0000 ..........d..... 59 | 0x0030: 0101 1a55 89a2 6951 ...U..iQ 60 | 61 | In cases where OS X "survives" the invalid enumeration, when the test packet 62 | is not immediately sent, invalid packets are witnessed being received on the 63 | OS X side. Such TCP/IP packets show contents from the payload of previous 64 | packets sent over the RNDIS interface, being detected as part of the header of 65 | new packets, hence generating invalid frames. This aspect is a clear 66 | indication of packet buffer misalignment. 67 | 68 | The issue has been addressed in OS X update v10.11.4 (Security Update 69 | 2016-002), the official Apple description for the vulnerability follows: 70 | 71 | https://support.apple.com/en-ca/HT206167 - AppleUSBNetworking 72 | 73 | Available for: OS X El Capitan v10.11 to v10.11.3 74 | 75 | Impact: An application may be able to execute arbitrary code with kernel 76 | privileges. 77 | 78 | Description: A memory corruption issue existed in the parsing of data from USB 79 | devices. This issue was addressed through improved input validation. 80 | 81 | CVE-ID CVE-2016-1734: Andrea Barisani and Andrej Rosano of Inverse Path 82 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_IPVR2018-0001-U-Boot_verified_boot_bypass.txt: -------------------------------------------------------------------------------- 1 | Security advisory: U-Boot verified boot bypass 2 | ============================================== 3 | 4 | The Universal Boot Loader - U-Boot [1] verified boot feature allows 5 | cryptographic authentication of signed kernel images, before their execution. 6 | 7 | This feature is essential in maintaining a full chain of trust on systems which 8 | are secure booted by means of an hardware anchor. 9 | 10 | Multiple techniques have been identified that allow to execute arbitrary code, 11 | within a running U-Boot instance, by means of externally provided 12 | unauthenticated data. 13 | 14 | All such techniques spawn from the lack of memory allocation protection within 15 | the U-Boot architecture, which results in several means of providing 16 | excessively large images during the boot process. 17 | 18 | Some implementers might find the following issues as an intrinsic 19 | characteristic of the U-Boot memory model, and consequently a mere aspect of 20 | correct U-Boot configuration and command restrictions. 21 | 22 | However in our opinion the inability of U-Boot to protect itself when loading 23 | binaries is an unexpected result of non trivial understanding, particularly 24 | important to emphasize in trusted boot scenarios. 25 | 26 | This advisory details two specific techniques that allow to exploit U-Boot lack 27 | of memory allocation restrictions, with the most severe case also detailing a 28 | workaround to mitigate the issue. 29 | 30 | It must be emphasized that cases detailed in the next sections only represent 31 | two possible occurrences of such architectural limitation, other U-Boot image 32 | loading functions are extremely likely to suffer from the same validation 33 | issues. 34 | 35 | To a certain extent the identified issues are similar to one of the findings 36 | reported as CVE-2018-1000205 [2], however they concern different functions 37 | which in some cases are at a lower level, therefore earlier in the boot image 38 | loading stage. 39 | 40 | Again all such issues are a symptom of the same core architectural limitation, 41 | being the lack of memory allocation constraints for received images. 42 | 43 | It is highly recommended, for implementers of trusted boot schemes, to review 44 | use of all U-Boot booting/loading commands, and not merely the two specific 45 | ones involved in the findings below, to apply limitations (where 46 | applicable/possible) to the size of loaded images in relation to the available 47 | RAM. 48 | 49 | It should also be emphasized that any trusted boot scheme must also rely on an 50 | appropriate lockdown of all possibilities for interactive consoles, by boot 51 | process interruption or failure, to ever be prompted. 52 | 53 | 54 | U-Boot insufficient boundary checks in filesystem image load 55 | ------------------------------------------------------------ 56 | 57 | The U-Boot bootloader supports kernel loading from a variety of filesystem 58 | formats, through the `load` command or its filesystem specific equivalents 59 | (e.g. `ext2load`, `ext4load`, `fatload`, etc.) 60 | 61 | These commands do not protect system memory from being overwritten when loading 62 | files of a length that exceeds the boundaries of the relocated U-Boot memory 63 | region, filled with the loaded file starting from the passed `addr` variable. 64 | 65 | Therefore an excessively large boot image, saved on the filesystem, can be 66 | crafted to overwrite all U-Boot static and runtime memory segments, and in 67 | general all device addressable memory starting from the `addr` load address 68 | argument. 69 | 70 | The memory overwrite can directly lead to arbitrary code execution, fully 71 | controlled by the contents of the loaded image. 72 | 73 | When verified boot is implemented, the issue allows to bypass its intended 74 | validation as the memory overwrite happens before any validation can take 75 | place. 76 | 77 | The following example illustrates the issue, triggered with a 129MB file on a 78 | machine with 128MB or RAM: 79 | 80 | ``` 81 | U-Boot 2018.09-rc1 (Oct 10 2018 - 10:52:54 +0200) 82 | 83 | DRAM: 128 MiB 84 | Flash: 128 MiB 85 | MMC: MMC: 0 86 | 87 | # print memory information 88 | => bdinfo 89 | arch_number = 0x000008E0 90 | boot_params = 0x60002000 91 | DRAM bank = 0x00000000 92 | -> start = 0x60000000 93 | -> size = 0x08000000 94 | DRAM bank = 0x00000001 95 | -> start = 0x80000000 96 | -> size = 0x00000004 97 | eth0name = smc911x-0 98 | ethaddr = 52:54:00:12:34:56 99 | current eth = smc911x-0 100 | ip_addr = 101 | baudrate = 38400 bps 102 | TLB addr = 0x67FF0000 103 | relocaddr = 0x67F96000 104 | reloc off = 0x07796000 105 | irq_sp = 0x67EF5EE0 106 | sp start = 0x67EF5ED0 107 | 108 | # load large file 109 | => ext2load mmc 0 0x60000000 fitimage.itb 110 | 111 | # In this specific example U-Boot falls in an infinite loop, results vary 112 | # depending on the test case and filesystem/device driver used. A debugging 113 | # session demonstrates memory being overwritten: 114 | (gdb) p gd 115 | $28 = (volatile gd_t *) 0x67ef5ef8 116 | (gdb) p *gd 117 | $27 = {bd = 0x7f7f7f7f, flags = 2139062143, baudrate = 2139062143, ... } 118 | (gdb) x/300x 0x67ef5ef8 119 | 0x67ef5ef8: 0x7f7f7f7f 0x7f7f7f7f 0x7f7f7f7f 0x7f7f7f7f 120 | ``` 121 | 122 | It can be seen that memory address belonging to U-Boot data segments, in this 123 | specific case the global data structure `gd`, is overwritten with payload 124 | originating from `fitimage.itb` (filled with `0x7f7f7f7f`). 125 | 126 | ### Impact 127 | 128 | Arbitrary code execution can be achieved within a U-Boot instance by means of 129 | unauthenticated binary images, loaded through the `load` command or its 130 | filesystem specific equivalents. 131 | 132 | It should be emphasized that all load commands are likely to be affected by the 133 | same underlying root cause of this vulnerability. 134 | 135 | ### Workaround 136 | 137 | The optional `bytes` argument can be passed to all load commands to restrict 138 | the maximum size of the retrieved data. 139 | 140 | The issue can be therefore mitigated by passing a `bytes` argument with a value 141 | consistent with the U-Boot memory regions mapping and size. 142 | 143 | 144 | U-Boot insufficient boundary checks in network image boot 145 | --------------------------------------------------------- 146 | 147 | The U-Boot bootloader supports kernel loading from a variety of network 148 | sources, such as TFTP via the `tftpboot` command. 149 | 150 | This command does not protect system memory from being overwritten when loading 151 | files of a length that exceeds the boundaries of the relocated U-Boot memory 152 | region, filled with the loaded file starting from the passed `loadAddr` 153 | variable. 154 | 155 | Therefore an excessively large boot image, served over TFTP, can be crafted to 156 | overwrite all U-Boot static and runtime memory segments, and in general all 157 | device addressable memory starting from the `loadAddr` load address argument. 158 | 159 | The memory overwrite can directly lead to arbitrary code execution, fully 160 | controlled by the contents of the loaded image. 161 | 162 | When verified boot is implemented, the issue allows to bypass its intended 163 | validation as the memory overwrite happens before any validation can take 164 | place. 165 | 166 | The issue can be exploited by several means: 167 | 168 | - An excessively large crafted boot image file is parsed by the 169 | `tftp_handler` function which lacks any size checks, allowing the memory 170 | overwrite. 171 | 172 | - A malicious server can manipulate TFTP packet sequence numbers to store 173 | downloaded file chunks at arbitrary memory locations, given that the 174 | sequence number is directly used by the `tftp_handler` function to calculate 175 | the destination address for downloaded file chunks. 176 | 177 | Additionally the `store_block` function, used to store downloaded file 178 | chunks in memory, when invoked by `tftp_handler` with a `tftp_cur_block` 179 | value of 0, triggers an unchecked integer underflow. 180 | 181 | This allows to potentially erase memory located before the `loadAddr` when 182 | a packet is sent with a null, following at least one valid packet. 183 | 184 | The following example illustrates the issue, triggered with a 129MB file on a 185 | machine with 128MB or RAM: 186 | 187 | ``` 188 | U-Boot 2018.09-rc1 (Oct 10 2018 - 10:52:54 +0200) 189 | 190 | DRAM: 128 MiB 191 | Flash: 128 MiB 192 | MMC: MMC: 0 193 | 194 | # print memory information 195 | => bdinfo 196 | arch_number = 0x000008E0 197 | boot_params = 0x60002000 198 | DRAM bank = 0x00000000 199 | -> start = 0x60000000 200 | -> size = 0x08000000 201 | DRAM bank = 0x00000001 202 | -> start = 0x80000000 203 | -> size = 0x00000004 204 | eth0name = smc911x-0 205 | ethaddr = 52:54:00:12:34:56 206 | current eth = smc911x-0 207 | ip_addr = 208 | baudrate = 38400 bps 209 | TLB addr = 0x67FF0000 210 | relocaddr = 0x67F96000 211 | reloc off = 0x07796000 212 | irq_sp = 0x67EF5EE0 213 | sp start = 0x67EF5ED0 214 | 215 | # configure environment 216 | => setenv loadaddr 0x60000000 217 | => dhcp 218 | smc911x: MAC 52:54:00:12:34:56 219 | smc911x: detected LAN9118 controller 220 | smc911x: phy initialized 221 | smc911x: MAC 52:54:00:12:34:56 222 | BOOTP broadcast 1 223 | DHCP client bound to address 10.0.0.20 (1022 ms) 224 | Using smc911x-0 device 225 | TFTP from server 10.0.0.1; our IP address is 10.0.0.20 226 | Filename 'fitimage.bin'. 227 | Load address: 0x60000000 228 | Loading: ################################################################# 229 | ... 230 | #################################### 231 | 232 | R00=7f7f7f7f R01=67fedf6e R02=00000000 R03=7f7f7f7f 233 | R04=7f7f7f7f R05=7f7f7f7f R06=7f7f7f7f R07=7f7f7f7f 234 | R08=7f7f7f7f R09=7f7f7f7f R10=0000d677 R11=67fef670 235 | R12=00000000 R13=67ef5cd0 R14=02427f7f R15=7f7f7f7e 236 | PSR=400001f3 -Z-- T S svc32 237 | ``` 238 | 239 | It can be seen that the program counter (PC, r15) is set to an address 240 | originating from `fitimage.itb` (filled with `0x7f7f7f7f`), as the result of 241 | the U-Boot memory overwrite. 242 | 243 | ### Impact 244 | 245 | Arbitrary code execution can be achieved within a U-Boot instance by means of 246 | unauthenticated binary images, passed through TFTP and loaded through the 247 | `tftpboot` command, or by a malicious TFTP server capable of sending arbitrary 248 | response packets. 249 | 250 | It should be emphasized that all network boot commands are likely to be 251 | affected by the same underlying root cause of this vulnerability. 252 | 253 | ### Workaround 254 | 255 | The `tftpboot` command lacks any optional argument to restrict the maximum size 256 | of downloaded images, therefore the only workaround at this time is to avoid 257 | using this command on environments that require trusted boot. 258 | 259 | 260 | Affected version 261 | ---------------- 262 | 263 | All tests have been performed against U-Boot version 2018.09-rc1. 264 | 265 | CVE-2018-18439 fixed in commit a156c47e39ad7d007c88919103ee0ee131c6203b 266 | CVE-2018-18440 fixed in commit aa3c609e2be5a837e7b81e308d47f55b67666bd6 267 | 268 | Both fixes are included in U-Boot v2019.04. 269 | 270 | 271 | Credit 272 | ------ 273 | 274 | Vulnerabilities discovered and reported by the Inverse Path team at F-Secure, 275 | in collaboration with Quarkslab. 276 | 277 | 278 | CVE 279 | --- 280 | 281 | CVE-2018-18440: U-Boot insufficient boundary checks in filesystem image load 282 | CVE-2018-18439: U-Boot insufficient boundary checks in network image boot 283 | 284 | 285 | Timeline 286 | -------- 287 | 288 | 2018-10-05: network boot finding identified during internal security audit 289 | by Inverse Path team at F-Secure in collaboration with Quarkslab. 290 | 291 | 2018-10-10: filesystem load finding identified during internal security audit 292 | by Inverse Path team at F-Secure. 293 | 294 | 2018-10-12: vulnerability reported by Inverse Path team at F-Secure to U-Boot 295 | core maintainer and Google security, embargo set to 2018-11-02. 296 | 297 | 2018-10-16: Google closes ticket reporting that ChromeOS is not affected due 298 | to their specific environment customizations. 299 | 300 | 2018-10-17: CVE IDs requested to MITRE and assigned. 301 | 302 | 2018-11-02: advisory release. 303 | 304 | 2019-04-09: U-Boot v2019.04 is released. 305 | 306 | 307 | References 308 | ---------- 309 | 310 | [1] https://www.denx.de/wiki/U-Boot 311 | [2] https://lists.denx.de/pipermail/u-boot/2018-June/330487.html 312 | 313 | 314 | Permalink 315 | --------- 316 | 317 | https://github.com/f-secure-foundry/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_IPVR2018-0001.txt 318 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_QBVR2017-0001-NXP_HAB_bypass.txt: -------------------------------------------------------------------------------- 1 | Security advisory: High Assurance Boot (HABv4) bypass 2 | ===================================================== 3 | 4 | The NXP i.MX53 System-on-Chip, main processor used in the USB armory Mk I board 5 | [1] design, suffers from vulnerabilities that allow bypass of the optional High 6 | Assurance Boot function (HABv4). 7 | 8 | The HABv4 [2] enables on-chip internal boot ROM authentication of the initial 9 | bootloader with a digital signature, establishing the first trust anchor for 10 | further code authentication. 11 | 12 | This functionality is commonly known as Secure Boot [3] and it can be activated 13 | by users who require authentication of the bootloader (e.g. U-Boot) to further 14 | maintain, and verify, trust of executed code. 15 | 16 | Quarkslab reported [4] to NXP, and subsequently to Inverse Path, two different 17 | techniques for bypassing HABv4 by means of exploiting validation errors in the 18 | SoC internal boot ROM [5], which are exposed before bootloader authentication 19 | takes place. 20 | 21 | While the two vulnerabilities have been initially reported for the i.MX6 SoC, 22 | Inverse Path evaluated that both issues also apply to the i.MX53 SoC, used on 23 | the USB armory Mk I. 24 | 25 | The HABv4 feature is not enabled by default on the USB armory Mk I and does not 26 | impact its normal operation. This advisory concerns only users that follow, and 27 | rely upon, the Secure Boot [3] procedure. See Impact section for a detailed 28 | analysis. 29 | 30 | X.509 parsing error (ERR010873) 31 | =============================== 32 | 33 | The initial HABv4 secure booting process can be summarized as follows: 34 | 35 | 1. Four Super Root Key (SRK) certification authorities are created. 36 | 37 | 2. A hash of the four concatenated SRK public keys is permanently fused in 38 | the SoC. 39 | 40 | 3. To sign the bootloader the boot image is integrated with a Command Sequence 41 | File (CSF), parsed by the SoC internal boot ROM in order to: 42 | 43 | A. Load the SRK public keys and verify that their concatenated hash matches 44 | the one fused in the SoC. 45 | 46 | B. Load the CSF signing public key. 47 | 48 | C. Authenticate the CSF signing public key with one of the SRK keys. 49 | 50 | D. Authenticate the CSF commands, which include the bootloader signature. 51 | 52 | The vulnerability takes place in the X.509 parsing of the CSF certificate which 53 | includes the signing public key (3.B). An excessively long `keyUsage` tag in 54 | the certificate triggers a stack overflow that can be leveraged to jump 55 | directly to the bootloader, bypassing authentication. 56 | 57 | The X.509 parsing error allows creation of bootloader images that, despite 58 | having an invalid signature, can be successfully booted on a device with HABv4 59 | in 'Closed' state. 60 | 61 | The parsing error does not require knowledge of the SRK public keys matching 62 | the fused hash (SRK table), as the certificate parsing step (3.B) can be forced 63 | as first command of the CSF. 64 | 65 | Inverse Path developed its own PoC [6] for the parsing error to confirm its 66 | application on the i.MX53 SoC, integrating it with the `usbarmory_csftool` 67 | utility, used to create USB armory Mk I signed bootloader images, by means of 68 | the added `--hab_poc` flag. 69 | 70 | SDP protection bypass (ERR010872) 71 | ================================= 72 | 73 | The i.MX53 boot ROM features a built-in recovery mode that allows execution of 74 | arbitrary code directly through USB when no other boot methods (e.g. microSD 75 | card) are detected. 76 | 77 | The Serial Download Protocol (SDP), used on such interface, is supposed to 78 | prevent arbitrary write access on boot ROM own memory when HABv4 is enabled. 79 | 80 | Such protection however suffer from incorrect validations, ultimately allowing 81 | overwrite of the boot ROM stack with consequent arbitrary code execution, which 82 | leads to HABv4 bypass. 83 | 84 | Impact 85 | ====== 86 | 87 | The HABv4 feature is not enabled by default on the USB armory Mk I and does not 88 | impact its normal operation. 89 | 90 | The Secure Boot [3] procedure is supported for specific use cases where 91 | authentication of the initial bootloader is required to further maintain a 92 | chain of trust. 93 | 94 | This scenario does not typically apply to Linux distributions, such as the USB 95 | armory Mk I default Debian image, as the chain of trust is typically lost 96 | between the kernel and userspace (and therefore tampering is always possible, 97 | regardless of Secure Boot). 98 | 99 | For environments with a complete chain of trust (e.g. embedded kernel ramdisk 100 | images) Secure Boot allows the first hardware anchor. 101 | 102 | The USB armory impact is evaluated with the following considerations: 103 | 104 | * The USB armory is an unconventional embedded device that promotes, through 105 | its custom form factor, defensive uses where the device is never left 106 | unattended and therefore preventing "Evil Maid" kind of attacks. 107 | 108 | Also it should be emphasized that Secure Boot protects the hardware from 109 | unauthenticated code, and not the other way around. Signed microSD cards can 110 | always be executed on any USB armory board without HABv4 enabled. 111 | 112 | For these reason the importance of Secure Boot, most valuable on unattended 113 | hardware, is marginal unless physical tampering or replacement of a valid 114 | microSD card is considered a potential threat. 115 | 116 | * The NXP Security Controller (SCCv2) Linux driver [7] allows AES encryption 117 | using the USB armory Mk I SoC internal key. The key cannot be read, but only 118 | used by means of the SCCv2, additionally the key is only activated when HABv4 119 | is enabled. 120 | 121 | The SCCv2 therefore allows device specific AES encryption/decryption and, 122 | while the secret key is only activated when HABv4 secure state is assured, 123 | compromise of the HABv4 does not constitute a key leak as it remains 124 | unreadable to the CPU. 125 | 126 | For this reason the SCCv2 functionality remains effective in terms of 127 | restricting AES encryption/decryption to a specific device with its own 128 | secret key. 129 | 130 | Additionally the SCCv2 use cases promoted by Inverse Path, for the USB 131 | armory, always consist of two-factor encryption. For instance the INTERLOCK 132 | [8] encryption front-end allows optional support for the SCCv2 to derive 133 | device specific keys always in combination with user provided passphrases. 134 | 135 | * The vulnerability remains critical for unattended setups that rely on the 136 | combination of Secure Boot and SCCv2 to protect cryptographic secrets, 137 | that are meant to be used without any user input (or network based 138 | challenge/response validation of the SCCv2 secret key). 139 | 140 | An example of such setup would be unattended deployments, without network 141 | connectivity, such as licensing tokens. 142 | 143 | Affected P/Ns 144 | ============= 145 | 146 | The reported [4] vulnerabilities affect High Assurance Boot version 4 (HABv4) 147 | present on multiple Freescale/NXP i.MX family of application processors. 148 | 149 | The i.MX53 family of processors, mounted on all USB armory Mk I boards, is 150 | affected by the X.509 parsing error and SDP protection bypass. 151 | 152 | Given that the internal boot ROM cannot be updated, only a new silicon revision 153 | by NXP, with an adequately patched boot ROM, can address the vulnerabilities. 154 | 155 | The list of affected NXP application processors can be found in the i.MX 156 | Community post titled "i.MX & Vybrid Security Vulnerability Errata" [10]. 157 | 158 | NXP is not releasing new i.MX53 revisions, therefore USB armory Mk I Secure 159 | Boot feature is deprecated. However the USB armory Mk II is produced with 160 | i.MX6UL parts with Silicon Revision 1.2 or greater, implemented on Part Numbers 161 | (P/N) with revision "AB" or greater, which address both issues. 162 | 163 | Credit 164 | ====== 165 | 166 | Vulnerability discovered and reported [4] by Guillaume Delugré and Kévin 167 | Szkudlapski of Quarkslab. 168 | 169 | i.MX53 PoC [6] developed by Andrea Barisani and Andrej Rosano of Inverse Path. 170 | 171 | CVE - NXP Erratum 172 | ================= 173 | 174 | CVE-2017-7936 - ERR010872 ROM: Secure boot vulnerability when using the Serial Downloader 175 | CVE-2017-7932 - ERR010873 ROM: Secure boot vulnerability when authenticating a certificate 176 | 177 | Timeline 178 | ======== 179 | 180 | 2017-05-18: Quarkslab presents findings at the 2017 Qualcomm Mobile Security 181 | Summit [9], materials are not disclosed to the public at this time. 182 | 2017-05-30: Quarkslab communicates embargo period until 2017-07-18. 183 | 2017-05-30: Inverse Path proposes preliminary advisory release on 2017-06-05. 184 | 2017-06-05: Inverse Path releases preliminary advisory. 185 | 2017-06-06: added assigned CVE numbers. 186 | 2017-07-19: Quarkslab public release of findings [4]. 187 | 2017-07-19: Inverse Path release of full advisory and i.MX53 PoC [6]. 188 | 2017-07-27: added link to i.MX Community post that lists affected P/Ns. 189 | 2019-11-08: added fixed P/Ns information for the USB armory Mk II. 190 | 191 | References 192 | ========== 193 | 194 | [1] https://github.com/inversepath/usbarmory/wiki 195 | [2] https://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf 196 | [3] https://github.com/inversepath/usbarmory/wiki/Secure-boot 197 | [4] https://blog.quarkslab.com/vulnerabilities-in-high-assurance-boot-of-nxp-imx-microprocessors.html 198 | [5] https://github.com/inversepath/usbarmory/wiki/Internal-Boot-ROM 199 | [6] https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/usbarmory_csftool#L227 200 | [7] https://github.com/inversepath/mxc-scc2 201 | [8] https://github.com/inversepath/interlock 202 | [9] https://qct-qualcomm.secure.force.com/QCTConference/GenericSitePage?eventname=2017Security&page=Summit%20Information 203 | [10] https://community.nxp.com/docs/DOC-334996 204 | 205 | Permalink 206 | ========= 207 | 208 | https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_QBVR2017-0001.txt 209 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_oCERT-2008-001-GnuPG_memory_corruption.txt: -------------------------------------------------------------------------------- 1 | oCERT-2008-001 GnuPG memory corruption 2 | 3 | Description: 4 | 5 | A memory corruption bug exists in version 1.4.8 of the Gnu Privacy Guard, the 6 | issue also affects version 2.0.8. 7 | 8 | A selection of keys available from a public keyserver were found to cause a 9 | segmentation fault due to pointer corruption when imported via --refresh-keys 10 | or --import. 11 | 12 | It is not known whether the bug can be exploited to execute arbitrary code. 13 | Version 1.4.9 and 2.0.9 have been released addressing this issue. 14 | 15 | We would like to thank Werner Koch (wk [at] gnupg [dot] org) for promptly 16 | handling this issue. 17 | 18 | Affected version: 19 | 20 | GnuGP = 1.4.8, = 2.0.8 21 | 22 | Fixed version: 23 | 24 | GnuGP >= 1.4.9, >= 2.0.9 25 | 26 | Credit: Andrea Barisani, oCERT Team | Inverse Path 27 | 28 | CVE: CVE-2008-1530 29 | 30 | Timeline: 31 | 32 | 2008-03-19: contacted gnupg maintainers and affected vendors 33 | 2008-03-25: gnupg patched in SVN 34 | 2008-03-26: gnupg 1.4.9, 2.0.9 released 35 | 2008-03-26: advisory release 36 | 2008-03-27: assigned CVE 37 | 38 | References: 39 | https:://bugs.g10code.com/gnupg/issue894 40 | -------------------------------------------------------------------------------- /Security_Advisory-Ref_oCERT-2008-014-WordNet_stack_overflows.txt: -------------------------------------------------------------------------------- 1 | oCERT-2008-014 WordNet stack and heap overflows 2 | 3 | Description: 4 | 5 | The WordNet 3.0 Unix library and command-line interface suffer from a number of 6 | stack overflows due to their handling of command line arguments, environment 7 | variables and data read from user supplied dictionaries. 8 | 9 | The oCERT team was contacted by Moritz Muehlenhoff from the Debian project 10 | requesting an audit of the WordNet code base. These vulnerabilities were the 11 | findings of the requested audit. 12 | 13 | Stack overflows fed via the command line, environment variables or WordNet 14 | library calls can result in arbitrary code execution. 15 | 16 | Stack and heap overflows via modified WordNet dictionaries may allow arbitrary 17 | code execution. 18 | 19 | It should be noted that despite the ease with which arbitrary code can be 20 | executed via these WordNet flaws, unless WordNet is being used by a daemon or 21 | web service running as a user other than that of the attacker, this is unlikely 22 | to result in privilege escalation or the ability to take any action not already 23 | possible as the attacking user. 24 | 25 | The following patch fixes the issues: 26 | http://ocert.org/analysis/2008-014/wordnet.patch.2 27 | 28 | Affected version: 29 | 30 | WordNet = 3.0 31 | 32 | Fixed version: 33 | 34 | Princeton unfortunately lack the resources to produce a new release of 35 | this code and will therefore not be releasing a new version as a result of 36 | this audit. 37 | 38 | Credit: Rob Holland, oCERT Team | Inverse Path Ltd 39 | 40 | CVE: CVE-2008-3908 41 | 42 | Timeline: 43 | 44 | 2008-06-02: audit requested 45 | 2008-06-25: first phase audit completed 46 | 2008-07-15: second phase audit completed 47 | 2008-07-19: report and patch sent upstream and to audit requester 48 | 2008-08-12: report and patch resent upstream due to lack of response 49 | 2008-08-13: upstream acknowledge issues 50 | 2008-09-01: advisory release 51 | 2008-09-04: assigned CVE 52 | 2008-09-06: patch updated due to bug, not security sensitive 53 | 54 | References: 55 | 56 | oCERT vulnerability analysis report 57 | http://ocert.org/analysis/2008-014/analysis.txt 58 | -------------------------------------------------------------------------------- /ssa-603476.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/f-secure-foundry/advisories/cff0dbe5cc5764018ad07f3938884f90f1417015/ssa-603476.pdf --------------------------------------------------------------------------------