I'm not so sure that CT-01-005 is an actual issue. Cure53 states the attacker
could cause an OOB by writing (presumably meaning passing this in) a negative
value for attributes_len.
1. attributes_len is set by calling hal_xdr_decode_int, it is not passed
into pkey_get_attributes. it's true that attributes_len is passed back in
hal_xdr_decode_int via *value = ntohl(**(uint32_t **)inbuf); but this is not
the same sitaution as CT-01-006
2. hal_xdr_decode has a buffer overflow check and the conditional check is
unsigned, therefore a signed value buffer overflow attack is not possile in my
sing opinion. using arm-non-eabi-objdump we see the conditonal check is b.n
without a cmp to set the cc.
*
/* buffer overflow check */
if (limit - *inbuf < (ptrdiff_t)sizeof(*value))
56: 2001 movs r0, #1
58: e001 b.n 5e <hal_xdr_decode_buffer_in_place+0x5e>
5a: 2001 movs r0, #1
return HAL_ERROR_XDR_BUFFER_OVERFLOW;
________________________________
From: Tech <tech-boun...@cryptech.is> on behalf of Phil Roberts
<robe...@dkey.org>
Sent: Tuesday, October 9, 2018 7:37:03 AM
To: tech@cryptech.is
Subject: [Cryptech Tech] Cure53 security audit
Hi folks,
Cure53 completed a security audit for us last month. The Cryptech core team
has begun updating the design and implemention
in accordance with the recommendations in the audit report. Furthermore, the
core team is reviewing and updating our development process and how to augument
the toolchain to ensure that an even higher, and more consistent quality
and level of security will be reached. It is expected that there will be
incremental updates to address the identified issues, and these will be
finished by the end of year.
Regards,
Phil
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
