Loading a TA, which is an ELF binary, triggers a lot of operations done on the content of the ELF structure/info which are under REE control. It would be preferable to fully authenticate the binary before doing any of those ELF related operations (loading segments etc). This will not prevent the ELF manipulation from going wrong, but it will move the threat from anyone on the REE accessing the binaries, to restricted people having a valid key to sign a binary.
e.g. for REE FS TA storage, the hash is verified only when full binary have been consumed, which is at the end of the ELF binding process. See ree_fs_ta.c::ta_read()
.
Additionally, this is a weak spot: a lot of operations rely on getting there, if the check_digest()
never happens for X reason, the caller will just keep going (effectively allowing a non-authenticated TA to run). No attack path where identified, but some may exist or may be introduced to alter either the handle->nw_ta_size
in ree_fs_ta.c
, or the state->data_len
in elf_load.c
allowing to bypass the digest check.
Patches
optee_os.git
- core: REE FS TAs: add option to verify signature before processing (7db24ad)
Workarounds
N/A
References
N/A
OP-TEE ID
OP-TEE-2019-0005
Reported by
Netflix (Bastien Simondi)
For more information
For more information regarding the security incident process in OP-TEE, please read the information that can be found when going to the "Security" page at https://www.trustedfirmware.org.
Loading a TA, which is an ELF binary, triggers a lot of operations done on the content of the ELF structure/info which are under REE control. It would be preferable to fully authenticate the binary before doing any of those ELF related operations (loading segments etc). This will not prevent the ELF manipulation from going wrong, but it will move the threat from anyone on the REE accessing the binaries, to restricted people having a valid key to sign a binary.
e.g. for REE FS TA storage, the hash is verified only when full binary have been consumed, which is at the end of the ELF binding process. See
ree_fs_ta.c::ta_read()
.Additionally, this is a weak spot: a lot of operations rely on getting there, if the
check_digest()
never happens for X reason, the caller will just keep going (effectively allowing a non-authenticated TA to run). No attack path where identified, but some may exist or may be introduced to alter either thehandle->nw_ta_size
inree_fs_ta.c
, or thestate->data_len
inelf_load.c
allowing to bypass the digest check.Patches
optee_os.git
Workarounds
N/A
References
N/A
OP-TEE ID
OP-TEE-2019-0005
Reported by
Netflix (Bastien Simondi)
For more information
For more information regarding the security incident process in OP-TEE, please read the information that can be found when going to the "Security" page at https://www.trustedfirmware.org.