[Cryptech Tech] Cure53 security audit

[Joachim Strömbergson]

Aloha!

Would a larder handle ID be possible and help?
That is using 64-bit or larger IDs.

Just a thought.

Regard,
JoachimS


On 2018-12-06 20:27, Paul Selkirk wrote:
> Phil pointed out that I wasn't clear on what action I was taking on the
> first three MCU vulnerabilities, and that I never got around to publicly
> addressing the last two.
> 
> As of my previous email, I had committed and pushed changes to fix
> CT-01-005, CT-01-006, and (implicitly) CT-01-007. I now consider those
> closed.
> 
> 
> CT-01-008 MCU: Session reuse via weak client handles (High)
> 
> The scenario is that an attacker can piggy-back on an existing logged-in
> client connection, by guessing the 32-bit client handle.
> 
> Whether (and how well) this works depends on how the client or mux
> connects to the USB serial driver. On my Ubuntu box, multiple clients
> can connect to /dev/ttyUSB0 without requiring special privileges.
> However, uncoordinated writes will collide, and uncoordinated reads will
> go to whoever calls read() on the file descriptor. If the mux is being
> used, it will read all, some, or none of a response from a non-mux-using
> client. In practical terms, this makes it unlikely that the attacker
> could, say, export the keys, because the mux would unwittingly intercept
> at least part of the response.
> 
> Any short-term solution would involve locking the USB serial device
> against multiple access, but I'm not enough of a Linux/BSD/MacOS/Windows
> guru to know if that's possible. Or, y'know, keep attackers off the host
> in the first place?
> 
> The long-term solution is, and always has been, Rob's secure channel
> proposal: https://wiki.cryptech.is/wiki/SecureChannel
> 
> 
> CT-01-009 MCU: OOB read/write via ASN.1 key files with large numbers (High)
> 
>> It was discovered that the function that parses ASN.1 keys does not
>> check the size of the key's numbers. This makes it possible to
>> corrupt memory and potentially execute arbitrary code by providing a
>> key with large numbers. The bug can be triggered by importing a
>> crafted key file.
>> ...
>> It is assumed that one of the ENDIAN_LITTLE or ENDIAN_BIG pair is
>> always defined, but in case FP_64BIT is defined as well, the length
>> in c is not checked and a->used can grow to a value that exceeds the
>> size of a->dp.  In turn, this results in an OOB read/write in
>> fp_mul_2d().
> 
> On the face of it, this is bogus, because the STM32 is 32-bit
> little-endian. However, on digging into it, I discovered that
> endian-ness wasn't defined, so fp_read_unsigned_bin() was falling
> through to the code they highlighted. When I defined ENDIAN_LITTLE,
> fp_read_unsigned_bin() was compiled with the optimized 32-bit code,
> which includes a length check.
> 
> (I don't know why the non-endian and/or 64-bit version wouldn't have a
> length check, but that's in third-party code that we don't want to
> change without good reason, and that we don't need to change now that
> it's no longer relevant.)
> 
> fp_read_unsigned_bin() is the only function in libtfm that cares about
> endian-ness, or even mentions the ENDIAN_LITTLE and ENDIAN_BIG symbols,
> so I'm not surprised we missed it in the initial porting.
> 
> In addition to fixing this potential vulnerability, the optimized code
> runs 485us faster. Over the course of 13000 calls/RSA signature, this
> adds up to 6.3ms/sig. Every little bit helps.
> 
> The libtfm Makefile has been patched and committed, so I consider this
> issue closed.
> 
> 				paul
> 
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech
> 


-- 
Med vänlig hälsning, Yours

Joachim Strömbergson
========================================================================
                               Assured AB
========================================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cryptech.is/archives/tech/attachments/20181207/5b2440f0/attachment.sig>