Paul Beesley | 1ed4cf2 | 2019-03-07 16:22:44 +0000 | [diff] [blame] | 1 | Advisory TFV-4 (CVE-2017-9607) |
| 2 | ============================== |
| 3 | |
Joel Hutton | 9e60563 | 2019-02-25 15:18:56 +0000 | [diff] [blame] | 4 | +----------------+-------------------------------------------------------------+ |
| 5 | | Title | Malformed Firmware Update SMC can result in copy or | |
| 6 | | | authentication of unexpected data in secure memory in | |
| 7 | | | AArch32 state | |
| 8 | +================+=============================================================+ |
Paul Beesley | 75017f2 | 2019-03-05 17:10:07 +0000 | [diff] [blame] | 9 | | CVE ID | `CVE-2017-9607`_ | |
Joel Hutton | 9e60563 | 2019-02-25 15:18:56 +0000 | [diff] [blame] | 10 | +----------------+-------------------------------------------------------------+ |
| 11 | | Date | 20 Jun 2017 | |
| 12 | +----------------+-------------------------------------------------------------+ |
| 13 | | Versions | None (only between 22 May 2017 and 14 June 2017) | |
| 14 | | Affected | | |
| 15 | +----------------+-------------------------------------------------------------+ |
| 16 | | Configurations | Platforms that use AArch32 BL1 plus untrusted normal world | |
| 17 | | Affected | firmware update code executing before BL31 | |
| 18 | +----------------+-------------------------------------------------------------+ |
| 19 | | Impact | Copy or authentication of unexpected data in the secure | |
| 20 | | | memory | |
| 21 | +----------------+-------------------------------------------------------------+ |
| 22 | | Fix Version | `Pull Request #979`_ (merged on 14 June 2017) | |
| 23 | +----------------+-------------------------------------------------------------+ |
| 24 | | Credit | ARM | |
| 25 | +----------------+-------------------------------------------------------------+ |
| 26 | |
| 27 | The ``include/lib/utils_def.h`` header file provides the |
| 28 | ``check_uptr_overflow()`` macro, which aims at detecting arithmetic overflows |
| 29 | that may occur when computing the sum of a base pointer and an offset. This |
| 30 | macro evaluates to 1 if the sum of the given base pointer and offset would |
| 31 | result in a value large enough to wrap around, which may lead to unpredictable |
| 32 | behaviour. |
| 33 | |
| 34 | The macro code is at line 52, referring to the version of the code as of `commit |
| 35 | c396b73`_: |
| 36 | |
| 37 | .. code:: c |
| 38 | |
| 39 | /* |
| 40 | * Evaluates to 1 if (ptr + inc) overflows, 0 otherwise. |
| 41 | * Both arguments must be unsigned pointer values (i.e. uintptr_t). |
| 42 | */ |
| 43 | #define check_uptr_overflow(ptr, inc) \ |
| 44 | (((ptr) > UINTPTR_MAX - (inc)) ? 1 : 0) |
| 45 | |
| 46 | This macro does not work correctly for AArch32 images. It fails to detect |
| 47 | overflows when the sum of its two parameters fall into the ``[2^32, 2^64 - 1]`` |
| 48 | range. Therefore, any AArch32 code relying on this macro to detect such integer |
| 49 | overflows is actually not protected. |
| 50 | |
| 51 | The buggy code has been present in ARM Trusted Firmware (TF) since `Pull Request |
| 52 | #678`_ was merged (on 18 August 2016). However, the upstream code was not |
| 53 | vulnerable until `Pull Request #939`_ was merged (on 22 May 2017), which |
| 54 | introduced AArch32 support for the Trusted Board Boot (TBB) feature. Before |
| 55 | then, the ``check_uptr_overflow()`` macro was not used in AArch32 code. |
| 56 | |
| 57 | The vulnerability resides in the BL1 FWU SMC handling code and it may be |
| 58 | exploited when *all* the following conditions apply: |
| 59 | |
| 60 | - Platform code uses TF BL1 with the ``TRUSTED_BOARD_BOOT`` build option. |
| 61 | |
| 62 | - Platform code uses the Firmware Update (FWU) code provided in |
| 63 | ``bl1/bl1_fwu.c``, which is part of the TBB support. |
| 64 | |
| 65 | - TF BL1 is compiled with the ``ARCH=aarch32`` build option. |
| 66 | |
| 67 | In this context, the AArch32 BL1 image might fail to detect potential integer |
| 68 | overflows in the input validation checks while handling the |
| 69 | ``FWU_SMC_IMAGE_COPY`` and ``FWU_SMC_IMAGE_AUTH`` SMCs. |
| 70 | |
| 71 | The ``FWU_SMC_IMAGE_COPY`` SMC handler is designed to copy an image into secure |
| 72 | memory for subsequent authentication. This is implemented by the |
| 73 | ``bl1_fwu_image_copy()`` function, which has the following function prototype: |
| 74 | |
| 75 | .. code:: c |
| 76 | |
| 77 | static int bl1_fwu_image_copy(unsigned int image_id, |
| 78 | uintptr_t image_src, |
| 79 | unsigned int block_size, |
| 80 | unsigned int image_size, |
| 81 | unsigned int flags) |
| 82 | |
| 83 | ``image_src`` is an SMC argument and therefore potentially controllable by an |
| 84 | attacker. A very large 32-bit value, for example ``2^32 -1``, may result in the |
| 85 | sum of ``image_src`` and ``block_size`` overflowing a 32-bit type, which |
| 86 | ``check_uptr_overflow()`` will fail to detect. Depending on its implementation, |
| 87 | the platform-specific function ``bl1_plat_mem_check()`` might get defeated by |
| 88 | these unsanitized values and allow the following memory copy operation, that |
| 89 | would wrap around. This may allow an attacker to copy unexpected data into |
| 90 | secure memory if the memory is mapped in BL1's address space, or cause a fatal |
| 91 | exception if it's not. |
| 92 | |
| 93 | The ``FWU_SMC_IMAGE_AUTH`` SMC handler is designed to authenticate an image |
| 94 | resident in secure memory. This is implemented by the ``bl1_fwu_image_auth()`` |
| 95 | function, which has the following function prototype: |
| 96 | |
| 97 | .. code:: c |
| 98 | |
| 99 | static int bl1_fwu_image_auth(unsigned int image_id, |
| 100 | uintptr_t image_src, |
| 101 | unsigned int image_size, |
| 102 | unsigned int flags) |
| 103 | |
| 104 | Similarly, if an attacker has control over the ``image_src`` or ``image_size`` |
| 105 | arguments through the SMC interface and injects high values whose sum overflows, |
| 106 | they might defeat the ``bl1_plat_mem_check()`` function and make the |
| 107 | authentication module read data outside of what's normally allowed by the |
| 108 | platform code or crash the platform. |
| 109 | |
| 110 | Note that in both cases, a separate vulnerability is required to leverage this |
| 111 | vulnerability; for example a way to get the system to change its behaviour based |
| 112 | on the unexpected secure memory accesses. Moreover, the normal world FWU code |
| 113 | would need to be compromised in order to send a malformed FWU SMC that triggers |
| 114 | an integer overflow. |
| 115 | |
| 116 | The vulnerability is known to affect all ARM standard platforms when enabling |
| 117 | the ``TRUSTED_BOARD_BOOT`` and ``ARCH=aarch32`` build options. Other platforms |
| 118 | may also be affected if they fulfil the above conditions. |
| 119 | |
Paul Beesley | 75017f2 | 2019-03-05 17:10:07 +0000 | [diff] [blame] | 120 | .. _CVE-2017-9607: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9607 |
Joel Hutton | 9e60563 | 2019-02-25 15:18:56 +0000 | [diff] [blame] | 121 | .. _commit c396b73: https://github.com/ARM-software/arm-trusted-firmware/commit/c396b73 |
| 122 | .. _Pull Request #678: https://github.com/ARM-software/arm-trusted-firmware/pull/678 |
| 123 | .. _Pull Request #939: https://github.com/ARM-software/arm-trusted-firmware/pull/939 |
| 124 | .. _Pull Request #979: https://github.com/ARM-software/arm-trusted-firmware/pull/979 |