Newlib 3.3.0 vulnerability

[SharonVEC]

Hello,

I have a project created with STM32CubeIDE that includes FreeRTOS.
A Black Duck vulnerability scan was made on this project and a single vulnerability (CVE-2021-3420) was detected.

This vulnerability describes a flaw in Newlib 3.3.0 (all versions before 4.0.0) which causes some newlib functions (mEMALIGn, pvALLOc, nano_memalign, nano_valloc, nano_pvalloc) to be unsafe with overflow conditions.

All the files that are tied to this vulnerability by the scan are files sourced from arm-none-eabi that the IDE toolchain (GNU Tools for STM32(11.3 rel1)) uses to build my project.

I am not sure how to fix this "vulnerability" in my project since I can't change how ARM implemented its build toolchain which STM32 is using.
I am hoping I can somehow validate that my project does not use these compromised functions.
From what I can tell, isn't this a problem for every user of arm-none-eabi-gcc?

Am I doing something wrong? Can I somehow reject this vulnerability or fix it?

Thanks.

[Pavel A.]

Sources and build files for the newlib in latest CubeIDE toolchain can be found here:

https://github.com/STMicroelectronics/gnu-tools-for-stm32/tree/12.3.rel1/src/newlib

According to this it is version  4.3.0.

All releases: https://github.com/STMicroelectronics/gnu-tools-for-stm32/tags

If a simple update of the toolchain can get rid of the CVE concern (and won't break code or cause impossible testing burden!) why not to update.

[SharonVEC]

@Pavel A. Thank you for your response.

In my Black Duck scan, a newer version of newlib is indeed being detected (4.1.0) which is probably from the releases you are referencing.

This version indeed does not include a vulnerability and is being referenced by _newlib_version.h & time.h files in my scan. These files are sourced from arm-none-eabi in the toolchain's tools folder.

Unfortunately, newlib 3.3.0 is also detected by the scan and is referenced by:
errno.h, features.h, _intsup.h, _locale.h, reent.h, signal.h, stdlib.h, strings.h, times.h, _timespec.h, _timeval.h, _types.h, types.h

All these files are included in the same arm-none-eabi folder in the toolchain's tools folder.

From my understanding, if I change from 11.3 rel1 toolchain to the latest 12.3 rel1 the vulnerability will still be present since the toolchain still uses the same arm-none-eabi version.

Is it correct to assume that the toolchain does not use these files from arm-none-eabi? these seem like very common libraries.

[Pavel A.]

If you delete the old toolchain and leave only the latest, will this scanner still complain? If yes, send them a bug.

[CMYL]

Hello @SharonVEC 

Can you check with the new STM32CubeIDE version 1.15, it integrates the GCC 12 as default toolchain, newlib-4.2.0

[CMYL]

Hi @SharonVEC 

To clarify if it is a vulnerability matter or not you need to report any potential security vulnerability to ST PSIRT at psirt@st.com

Your report will be via a secure connection, you can see the guidelines in Report potential product security vulnerabilities - STMicroelectronics 

Best regards

[SharonVEC]

@CMYL @Pavel A. 

Sorry for my late reply.

Thank you very much for your response, I was skeptical but upgrading the toolchain to 12.3 rel1 removed the vulnerability issue.

I am a bit flustered about why this solved the issue since from my understanding the toolchain uses the same arm-none-eabi-gcc.

Is it because ST's toolchain overrides newlib with newlib_nano which is detected as a higher version? or I got this completely wrong?

[Pavel A.]

> Is it because ST's toolchain overrides newlib with newlib_nano which is detected as a higher version? 

This is very likely.

[CMYL]

Hi @Pavel A. and @SharonVEC,

I need to share with CubeIDE/Toolchain team to get a confirmed answer.

Internal Ticket 180016 Submitted to confirm if the root cause is because ST's toolchain overrides newlib with newlib_nano or something else.

This ticket is internal, it is put in this reply for tracking.

Best Regards

[Pavel A.]

@CMYL thank you for looking at this case. IMHO all we need here is to verify that all variants of newlib (nano) supplied with recent stm32 toolchains are good, without known CVE issues. This is NOT about CubeIDE setup overwriting something.