Hello Manuel,
I am hoping somebody may recognise the issue.
Otherwise we could update to 2.28.1 (and spend time doing that, plus back-editing various patches) and find that it doesn't fix it.
Updating to v3 is reportedly a LOT of work.
This is almost certainly not a security vulnerability.
Apart from this issue, the MbedTLS code has been working solidly for a couple of years.
Interestingly it happens only on the ST port of MbedTLS, not on a Windows compilation of MbedTLS.
Regards,
Peter
Hi Peter,
Mbed TLS v2.16.2 is no longer maintained. I would strongly recommend you, and in fact everyone, to use a maintained version of Mbed TLS. Currently the two maintained versions are 2.28.1 (2.28.x is the current LTS branch) and 3.2.1 (3.x is where new features arrive). Versions that are no longer maintained have publicly known security vulnerabilities.
(I didn't analyze the specific problem you're facing so I can't say if this is something that has been fixed in the meantime.)
Best regards, Manuel.
From: Peter via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: 06 December 2022 17:25 To: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] MbedTLS crashes with some websites in mbedtls_mpi_free()
Hi All,
Some websites crash MbedTLS, in
void mbedtls_ecp_point_free( mbedtls_ecp_point *pt ) { if( pt == NULL ) return;
mbedtls_mpi_free( &( pt->X ) ); mbedtls_mpi_free( &( pt->Y ) ); mbedtls_mpi_free( &( pt->Z ) ); }
It crashes in the last function call of the three above.
Thread #1 [main] 1 [core: 0] (Suspended : Signal :SIGTRAP:Trace/breakpoint trap) HardFault_Handler() at stm32f4xx_it.c:103 0x8053c22 <signal handler called>() at 0xffffffed 0x3810180 mbedtls_ecp_point_free() at ecp.c:594 0x8029c7a 0x81030100
It crashes properly i.e. invalid opcodes etc.
There is a fair bit on google with others having gone down the same road, never resolved.
One site which does it is socata.org but quite a few others do it. Probably 10% of "major name" websites cause it to crash.
It may have been undiscovered for a long time, or ever, because most MbedTLS clients are connecting to specific private servers only. People aren't using it to connect to microsoft.com (which doesn't actually crash but the handshake returns 0x2700 which can be investigated).
There is a Windows build of MbedTLS (v2.16.2) which seems to work in the crashing cases. Stepping through this in Cube IDE (32F417) it looks like the crash is due to a buffer being filled with random numbers. The guy working on this is contactable only on Monday afternoons so I am a bit screwed :) He said he found something about that buffer, or maybe a corrupted function pointer.
But as I said this issue has come up before according to numerous online searches and maybe someone can recognise it.
Hardware AES is enabled but this occurs with software AES also. No other 32F417 hardware crypto features are used, other than its random number generator.
TLS is v2.16.2.
Thank you in advance for any pointers.
Peter