Bob continues his open-source FreeRTOS series. In this sixth part, he will explore security issues and preventive measures when using FreeRTOS.
A few years ago, before the advent of the internet, I consulted a friend working at Bell Labs about network security issues. At that time, Bell Telephone Company enjoyed a government-sanctioned monopoly over the telephone system. Bell Labs was closely related to securing the telephone network. I was completely unaware that the devices I designed needed security. But he opened my eyes to a whole new world. During his time at Bell Labs, he had covertly attended phone hacking conferences (the popular term at the time was “phone phreaking” [1]). He introduced me to various hacking techniques used to obtain free long-distance calls. At that time, Bell Labs used a single frequency to control routing decisions in the telephone network. You could even use a whistle hidden in a box of Cap’n Crunch cereal (Figure 1) to make long-distance calls [2].
Figure 1 Even the sound from a whistle hidden in a box of Cap’n Crunch cereal could be used to make long-distance calls.
Although I encountered the dark side of hacking early in my design career and the necessity of creating anti-hacking embedded systems, I remained largely unaware of the depths of hacking techniques over the years. The emergence of the Stuxnet worm and its method of attacking Iranian PLCs should have shown us the true extent of hacking attacks—especially when hackers are government-sponsored. This worm caused the centrifuges used for enriching nuclear fuel to self-destruct, significantly slowing down Iran’s nuclear program [3].
Now, we face another threat from a cottage industry that has developed around individuals and small companies dedicated to finding security vulnerabilities in systems like yours! Not for the purpose of intrusion, but to establish a reputation in the software security industry for themselves and their companies. In 2019, Wind River’s VxWorks RTOS was exposed by one such company, which discovered 11 vulnerabilities in its network protocols used in over 200 million critical devices. While these vulnerabilities were real, they did not affect those 200 million devices, but they severely damaged Wind River’s reputation and that of the company that discovered them: Armis [4]. This article will later discuss another company that exposed 11 security vulnerabilities in FreeRTOS. However, I digress.
In this article, we will explore security issues when using FreeRTOS. We will examine it from two perspectives: what kind of security any RTOS should provide, and what kind of security FreeRTOS offers.
Security Requirements for Real-Time Operating Systems (RTOS)
Claiming that your chosen real-time operating system (RTOS) should be flawless is unrealistic; it can never be achieved. However, certain flaws in aspects of an RTOS can create security vulnerabilities large enough for a truck to drive through. There are certain elements in the design of an RTOS that must be foolproof. These are the elements we need to focus on the most. What? Aren’t we designing all elements to be equally robust? Sorry, resources such as time and brainpower are indeed limited. We need to prioritize the level of attention given to each aspect of the design.
I believe the best way to identify areas that need to be foolproof is to look at past vulnerabilities in RTOS. I have mentioned two security vulnerability databases in other articles that can help us understand where the vulnerabilities in RTOS lie. See “IoT (Part 8): Security Vulnerabilities from OWASP” (Circuit Cellar 315, October 2016) [5]. Additionally, the Common Weakness Enumeration (CWE) database maintained by MITRE [6] provides many security vulnerabilities related to operating systems. In this article, I will refer to that database using CWE-XX. Here are three key areas where I believe bugs should be strategically eliminated. In my view, they require extra attention in the design of an RTOS.
Memory Management: It is well known that memory leaks can be exploited and cause the system to become inoperable (CWE-401). However, these are usually caused at the application level. Nevertheless, any use of dynamic memory in an RTOS must undergo rigorous analysis and operational testing to detect memory leaks. The memory management code itself must also be as foolproof as possible.
Buffer Management: Buffer overflow is another area that can be exploited (CWE-120). Therefore, all data movement in and out of buffers must strategically eliminate bugs.
Scheduler: Poorly designed schedulers can lead to priority inversion of tasks, which, if exploited, can cause external stimuli to crash the system, leading to system failure [7].
Best Practices in RTOS Design
RTOS should follow industry security best practices where applicable. Here are some of the most important points I believe are crucial for RTOS design.
Clear Dynamic Memory: RTOS dynamic memory management should clear dynamic memory upon release or creation to prevent information leakage between tasks (CWE-226).
Error Checking: The design of the RTOS should ensure that there are no unchecked errors (CWE-391). We once designed the world’s fastest disk defragmenter: Speedback. When we licensed it to an Israeli company, they found that we had many places with unchecked errors. Code reviews are the best way to uncover these issues.
Access: RTOS should have methods for secure identification and authorized access (CWE-294).
Multiple Independent Levels of Security (MILS): RTOS should support multi-layered security protections. Not all security eggs should be placed in one basket. See my article “IoT (Part 5): IoT Security,” which discusses methods for protecting the castle: moats, walls, gates, and if all else fails, boiling oil.
Firewalls: RTOS that supports networking should provide built-in firewalls.
Support for Official Encryption Certificates: Network communications and security services should implement standard encryption certificates (CWE-295).
Use of Industry Standard Cryptographic Libraries: Strong hashing or cryptographic libraries should be used.
Memory Management Unit (MMU): If the processor supports it, the RTOS should support the use of an MMU.
Resource Throttling: Measures similar to quotas (CWE-770) should be implemented to prevent resource exhaustion on devices. This way, the RTOS can protect the system from attacks that exceed typical design limits.
Support for Secure Boot and Execution: RTOS should provide secure boot and execution mechanisms.
Secure File System: When files are deleted, the RTOS should clear unused blocks in the file system.
Security Monitor: RTOS should provide some mechanism for auditing access attempts or operations (logins, resource activities) from the outside world.
RTOS Updates: As a last line of defense (boiling oil), the RTOS should provide secure and verifiable update methods. Of the 200,000 vulnerable VxWorks systems mentioned earlier, only a few have been updated.
Does FreeRTOS Meet the Standards?
So, how does FreeRTOS perform? Again, as I mentioned last time, we are not trying to make FreeRTOS into Linux or VxWorks. But does its security performance reach an acceptable level? In terms of certification, as of January 2021, FreeRTOS has passed SESIP Level 2 security assurance certification [9]. This certification tests a limited set of security requirements derived from the Common Criteria [10]. It does not include tests for physical attacks, internal attacks, or limited testing on systems with an MMU. Furthermore, it was tested using only one processor: NXP Semiconductors’ LPC54018 IoT module (Figure 2). Unless you are using that processor, much of your code is not certified.
Figure 2 NXP Semiconductors’ LPC540XX MCU
Additionally, at the end of February 2021, FreeRTOS received PSA certification on Infineon’s PSoC64 secure microcontroller (MCU) [11]. This is another independent IoT security validation framework. The fact that FreeRTOS has been ported to devices like the PSoC64, which has passed PSA hardware certification, is significant. The PSoC64 dual-core processor (Figure 3) is a dual-core device that includes one core for non-secure processing and one for secure processing, providing most of the latest security measures built into hardware, and it has been certified!
Figure 3 PSoC64 Dual-Core Processor
But is that enough? Let’s see how it measures up to our standards.
Reviewing Past Vulnerabilities: Of course, in terms of strategic bug-free design, we can focus on two points. Look at the last 10 versions and see how many contain security fixes. This can largely reflect its maturity in security. Secondly, we can look at the list of recorded vulnerabilities. Table 1 lists the last 10 versions of FreeRTOS. Four of those versions have included security fixes. This has its pros and cons. The good thing is that these vulnerabilities were discovered. The bad thing is that such a small RTOS has so many security issues.
Looking at Reported Vulnerabilities: If we search for FreeRTOS in the NIST database, we get some disturbing results [12]. There were some very serious security vulnerabilities in FreeRTOS before it was certified. In 2018, Ori Karliner from Zimperium Security Labs discovered 11 serious security vulnerabilities in FreeRTOS+TCP. A deep dive into any of these vulnerabilities reveals immaturity in the code. Many released systems had these vulnerabilities. Fortunately, these vulnerabilities have been discovered and addressed. Table 2 lists three recently reported security vulnerabilities.
Best Practices: Finally, how does FreeRTOS compare to the best practices I listed earlier? Table 3 lists the best practices for FreeRTOS and indicates whether it complies with my views. With a few exceptions, FreeRTOS has made significant progress in adopting all the best practices for secure systems.
Table 1 Lists the latest 10 versions of FreeRTOS. Four versions have fixed security issues.
Table 2 FreeRTOS Security Vulnerabilities
Table 3 Compliance with Best Practices
Conclusion
Most of the security measures we design into embedded systems are included in FreeRTOS. However, building secure embedded systems using any RTOS is not an easy task. We have only scratched the surface of a few, and only briefly introduced several. Next time, in Part Seven, we will discuss FreeRTOS+TCP.