Log4j and Zephyr

I have been asked several times about whether the log4j vulnerability affects Zephyr. There is kind of a tendency to give a glib answer “Zephyr is an embedded RTOS, and doesn’t run Java.” Although this is true, it is important to understand that Zephyr doesn’t live alone, especially as devices become more connected, and evaluating this vulnerability should still be done.

The first place to look is indeed the source code to the Zephyr project itself. For the most part, Zephyr targets small embedded CPUs (microcontrollers) that frequently have memory sizes that are measured in tens or hundreds of kilobytes, with megabytes being available in a large system. A simple glance at the latest Apache log4j shows that the core jar file is 1.8 megabytes itself. Just the jarfile alone is larger than the memory on the targets that Zephyr supports.

Digging a little deeper, we see that log4j is a Java library. Java is used in many small types of devices, such as cell phones. However, as far as I know, it is not used in this microcontroller space, mostly due to space. The JVM (the application that runs programs written in Java) is 10s of megabytes itself, and typically wants the types of resources that are available in something like Linux.

If Zephyr starts to gain support for larger systems, it is conceivable that Java support could be added. It is likely by then that the versions affected by this vulnerability will be old enough to not really apply. However, it will be important to be aware of the possibilities.

Since the Zephyr code itself isn’t directly impacted by the log4j vulnerability, what others areas might we have to consider. The first other place to look would be the various pieces of infrastructure used to manage the project. Since the log4j vulnerability allows remote code execution, if one of these systems is vulnerable, it could be exploited to modify information about the project, or even allow the code itself to be modified.

For the most part, hosting for the infrastructure behind the Zephyr project is done through paid services. Although it may be worthwhile for the project to contact these providers to make sure this vulnerability is being addressed, due to the large nature and visibility of this issue, most vendors will be fairly proactive in addressing issues.

Many of the concerns on the OpenSSF Best Practices site are helpful in keeping vulnerabilities such as this from having a greater impact than they otherwise would. Maintaining a gold badge status also requires the Zephyr project to keep track of the vendors used to provide hosting.

A more difficult area to investigate is the infrastructure surrounding a given product that is produced using Zephyr. These are beyond the scope of the Zephyr project itself, but it is still important for these vendors to ensure that their systems will not be affected by this.

The Vulnerability Guideance project contains some useful information in this regards.