[Cryptech Tech] Cure53 security audit

[Michael Dockter]

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-bounces at cryptech.is> on behalf of Phil Roberts <roberts at dkey.org>
Sent: Tuesday, October 9, 2018 7:37:03 AM
To: tech at 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20181010/5a33bf04/attachment.html>