mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-08 05:43:53 +00:00
dc35bd320c
Change-Id: I31ebee7574f5133aadbf2767377fd74a21775ce5 Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
159 lines
8.8 KiB
ReStructuredText
159 lines
8.8 KiB
ReStructuredText
Advisory TFV-10 (CVE-2022-47630)
|
|
================================
|
|
|
|
+----------------+-------------------------------------------------------------+
|
|
| Title | Incorrect validation of X.509 certificate extensions can |
|
|
| | result in an out-of-bounds read. |
|
|
+================+=============================================================+
|
|
| CVE ID | `CVE-2022-47630`_ |
|
|
+----------------+-------------------------------------------------------------+
|
|
| Date | Reported on 12 Dec 2022 |
|
|
+----------------+-------------------------------------------------------------+
|
|
| Versions | v1.2 to v2.8 |
|
|
| Affected | |
|
|
+----------------+-------------------------------------------------------------+
|
|
| Configurations | BL1 and BL2 with Trusted Boot enabled with custom, |
|
|
| Affected | downstream usages of ``get_ext()`` and/or ``auth_nvctr()`` |
|
|
| | interfaces. Not exploitable in upstream TF-A code. |
|
|
+----------------+-------------------------------------------------------------+
|
|
| Impact | Out-of-bounds read. |
|
|
+----------------+-------------------------------------------------------------+
|
|
| Fix Version | - `fd37982a19a4a291`_ "fix(auth): forbid junk after |
|
|
| | extensions" |
|
|
| | |
|
|
| | - `72460f50e2437a85`_ "fix(auth): require at least one |
|
|
| | extension to be present" |
|
|
| | |
|
|
| | - `f5c51855d36e399e`_ "fix(auth): properly validate X.509 |
|
|
| | extensions" |
|
|
| | |
|
|
| | - `abb8f936fd0ad085`_ "fix(auth): avoid out-of-bounds read |
|
|
| | in auth_nvctr()" |
|
|
| | |
|
|
| | Note that `72460f50e2437a85`_ is not fixing any |
|
|
| | vulnerability per se but it is required for |
|
|
| | `f5c51855d36e399e`_ to apply cleanly. |
|
|
+----------------+-------------------------------------------------------------+
|
|
| Credit | Demi Marie Obenour, Invisible Things Lab |
|
|
+----------------+-------------------------------------------------------------+
|
|
|
|
This security advisory describes a vulnerability in the X.509 parser used to
|
|
parse boot certificates in TF-A trusted boot: it is possible for a crafted
|
|
certificate to cause an out-of-bounds memory read.
|
|
|
|
Note that upstream platforms are **not** affected by this. Only downstream
|
|
platforms may be, if (and only if) the interfaces described below are used in a
|
|
different context than seen in upstream code. Details of such context is
|
|
described in the rest of this document.
|
|
|
|
To fully understand this security advisory, it is recommended to refer to the
|
|
following standards documents:
|
|
|
|
- `RFC 5280`_, *Internet X.509 Public Key Infrastructure Certificate and
|
|
Certificate Revocation List (CRL) Profile*.
|
|
|
|
- `ITU-T X.690`_, *ASN.1 encoding rules: Specification of Basic Encoding Rules
|
|
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
|
|
(DER).*
|
|
|
|
Bug 1: Insufficient certificate validation
|
|
------------------------------------------
|
|
|
|
The vulnerability lies in the following source file:
|
|
``drivers/auth/mbedtls/mbedtls_x509_parser.c``. By design, ``get_ext()`` does
|
|
not check the return value of the various ``mbedtls_*()`` functions, as
|
|
``cert_parse()`` is assumed to have guaranteed that they will always succeed.
|
|
However, it passes the end of an extension as the end pointer to these
|
|
functions, whereas ``cert_parse()`` passes the end of the ``TBSCertificate``.
|
|
Furthermore, ``cert_parse()`` does not check that the contents of the extension
|
|
have the same length as the extension itself. It also does not check that the
|
|
extension block extends to the end of the ``TBSCertificate``.
|
|
|
|
This is a problem, as ``mbedtls_asn1_get_tag()`` leaves ``*p`` and ``*len``
|
|
undefined on failure. In practice, this results in ``get_ext()`` continuing to
|
|
parse at different offsets than were used (and validated) by ``cert_parse()``,
|
|
which means that the in-bounds guarantee provided by ``cert_parse()`` no longer
|
|
holds. The result is that it is possible for ``get_ext()`` to read memory past
|
|
the end of the certificate. This could potentially access memory with dangerous
|
|
read side effects, or leak microarchitectural state that could theoretically be
|
|
retrieved through some side-channel attacks as part of a more complex attack.
|
|
|
|
Bug 2: Missing bounds check in ``auth_nvctr()``
|
|
-----------------------------------------------
|
|
``auth_nvctr()`` does not check that the buffer provided is
|
|
long enough to hold an ``ASN.1 INTEGER``. Since ``auth_nvctr()`` will only ever
|
|
read 6 bytes, it is possible to read up to 6 bytes past the end of the buffer.
|
|
|
|
Exploitability Analysis
|
|
-----------------------
|
|
|
|
Upstream TF-A Code
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
In upstream TF-A code, the only caller of ``auth_nvctr()`` takes its input from
|
|
``get_ext()``, which means that the second bug is exploitable, so is the first.
|
|
Therefore, only the first bug need be considered.
|
|
|
|
All standard chains of trust provided in TF-A source tree (that is, under
|
|
``drivers/auth/``) require that the certificate's signature has already been
|
|
validated prior to calling ``get_ext()``, or any function that calls ``get_ext()``.
|
|
Platforms taking their chain of trust from a dynamic configuration file (such as
|
|
``fdts/tbbr_cot_descriptors.dtsi``) are also safe, as signature verification will
|
|
always be done prior to any calls to ``get_ext()`` or ``auth_nvctr()`` in this
|
|
case, no matter the order of the properties in the file. Therefore, it is not
|
|
possible to exploit this vulnerability pre-authentication in upstream TF-A.
|
|
|
|
Furthermore, the data read through ``get_ext()`` only
|
|
ever gets used by the authentication framework (``drivers/auth/auth_mod.c``),
|
|
which greatly reduces the range of inputs it will ever receive and thus the
|
|
impact this has. Specifically, the authentication framework uses ``get_ext()``
|
|
in three cases:
|
|
|
|
1. Retrieving a hash from an X.509 certificate to check the integrity of a
|
|
child certificate (see ``auth_hash()``).
|
|
|
|
2. Retrieving the signature details from an X.509 certificate to check its
|
|
authenticity and integrity (see ``auth_signature()``).
|
|
|
|
3. Retrieving the security counter value from an X.509 certificate to protect
|
|
it from unauthorized rollback to a previous version (see ``auth_nvctr()``).
|
|
|
|
None of these uses authentication framework write to the out-of-bounds memory,
|
|
so no memory corruption is possible.
|
|
|
|
In summary, there are 2 separate issues - one in ``get_ext()`` and another one
|
|
in ``auth_nvctr()`` - but neither of these can be exploited in the context of
|
|
TF-A upstream code.
|
|
|
|
Only in the following 2 cases do we expect this vulnerability to be triggerable
|
|
prior to authentication:
|
|
|
|
- The platform uses a custom chain of trust which uses the non-volatile counter
|
|
authentication method (``AUTH_METHOD_NV_CTR``) before the cryptographic
|
|
authentication method (``AUTH_METHOD_SIG``).
|
|
|
|
- The chain of trust uses a custom authentication method that calls
|
|
``get_ext()`` before cryptographic authentication.
|
|
|
|
Custom Image Parsers
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If the platform uses a custom image parser instead of the certificate parser,
|
|
the bug in the certificate parser is obviously not relevant. The bug in
|
|
``auth_nvctr()`` *may* be relevant, but only if the returned data is:
|
|
|
|
- Taken from an untrusted source (meaning that it is read prior to
|
|
authentication).
|
|
|
|
- Not already checked to be a primitively-encoded ASN.1 tag.
|
|
|
|
In particular, if the custom image parser implementation wraps a 32-bit integer
|
|
in an ASN.1 ``INTEGER``, it is not affected.
|
|
|
|
.. _CVE-2022-47630: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47630
|
|
.. _fd37982a19a4a291: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=fd37982a19a4a291
|
|
.. _72460f50e2437a85: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=72460f50e2437a85
|
|
.. _f5c51855d36e399e: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=f5c51855d36e399e
|
|
.. _abb8f936fd0ad085: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=abb8f936fd0ad085
|
|
.. _RFC 5280: https://www.ietf.org/rfc/rfc5280.txt
|
|
.. _ITU-T X.690: https://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf
|