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