Embedded News




Express Logic Response to Vulnerability Report on Marvell Avastar Wi-Fi

San Diego, CA, January 22, 2019

Express Logic takes safety and security very seriously – so much so that we have worked very hard to achieve the industry’s only deeply embedded SIL 4, ASIL D, and EAL4+ pre-certified run-time solutions. As such, it’s easy to understand why we were quite alarmed to hear of the recent vulnerability report on the Marvell Avastar 88W8897 Wi-Fi System-on-Chip (SoC) that uses our ThreadX RTOS.

After analyzing the report and media statements regarding the ThreadX-related aspect, we consulted with the author of the initial security analysis who suggested that some of the media reports may have misunderstood the angle and that the security issues described in the original article were not rooted in ThreadX itself. The bottom line is that this vulnerability is not a systemic problem in the ThreadX RTOS. The application firmware and drivers running on the Avastar 88W8897 SoC are solely responsible for and have complete control over the memory corruption cited in this report. In fact, the problem as described could occur on any RTOS, OS, or even without an RTOS. In summary, the vulnerability cited by the author lies with the application firmware, and has absolutely nothing to do with the ThreadX RTOS itself. Hence, none of the extensive 6.2 billion deployments using the ThreadX RTOS are in any way compromised by the ThreadX RTOS code or behavior. This is entirely an application firmware issue.

We would like to thank the author for bringing this issue to the forefront, creating a very valuable learning moment. Handling packets properly is an absolute necessity for IoT application firmware especially since such packets represent one of the most vulnerable means of a denial of service attack. This issue is also a great lesson in defensive programming – application firmware should always ensure that the destination memory is large enough to hold the payload, and not simply copy without checking for possible buffer overflow. Finally, there is also a lesson about how much visibility a SDK should provide into the application firmware. The access allowed by the SDK in this example was quite broad and therefore made reverse engineering relatively easy. Going forward, we will communicate these important lessons with our customer base as well as the general embedded IoT community and hopefully help avoid such pitfalls in the future.

Subscribe to our news