Bob continues his article series about the open-source FreeRTOS. In Part 6, he discusses security concerns and provisions when we use FreeRTOS.
A number of years ago, long before the Internet, I asked a friend who worked at Bell Labs about network security. At the time, the Bell Telephone Company had a government-sanctioned monopoly on the phone system. Bell Labs was integrally connected to protecting the security of the phone network. I was completely naïve about the needs for security in the devices I was designing. But he opened my eyes to a different world. Several times during his tenure at Bell Labs, he attended a phone hacker conference incognito (the popular term was “phone phreaks” [1]). He told me about all kinds of hacking techniques that were used to get free long-distance calling. At that time, Bell used single frequencies to cause the phone network to make decisions about routing calls. You could even use a whistle packaged in Captain Crunch (Figure 1) cereal to make long distance calls [2].
Even the sounds from this whistle packaged in Captain Crunch cereal could be used as a hack to make long distance calls.
Even though I was exposed early on in my design career to the dark side of hacking and the need to create hacker proof embedded systems, I largely remained in the dark for many years about the extent hackers would go. The advent of the Stuxnet worm and the way it compromised Iranian PLCs should show us the extent to which hackers actually go—especially when the hackers are government funded. This worm caused centrifuges used to create enriched nuclear fuel to self-destruct, which significantly slowed down the Iranian nuclear program [3].
Now we have another threat by way of the cottage industry that has developed around individuals and small companies who spend their careers trying to find security holes in systems like yours! Not to hack, but to make a name for themselves and their companies in the software security industry. In 2019, Wind River’s VxWorks RTOS got written up by one such company that exposed 11 vulnerabilities in its network protocols used in more than 200 million critical devices. These vulnerabilities, though real, never impacted the 200 million devices but definitely impacted Wind River’s reputation as well as the company that found the vulnerabilities: Armis [4]. Later in this article, we will discuss another such firm that wrote up 11 security vulnerabilities in FreeRTOS. But I am getting ahead of myself.
This month we will look at the security concerns with using FreeRTOS. We will look at it from two angles: What kind of security does any RTOS need to offer? And what kind of security does FreeRTOS offer?
SECURITY NEEDS IN AN RTOS
It’s not realistic to say that the RTOS you choose should be bug free. That will never happen. But bugs in certain aspects of an RTOS can create security holes large enough to drive a truck through. There are some areas of the design of an RTOS that need to be bulletproof. And those are the areas that need the most attention. What? Do we not design all areas equally robustly? Sorry, but resources like time and brain power are in short supply. We do need to prioritize the level of attention we pay to all aspects of our design.
I would say the best approach to identify areas that need to be bulletproof is to look at where RTOSes have been vulnerable in the past. There are two databases of security vulnerabilities that I have mentioned in other articles that can help us to know where an RTOS is vulnerable. Check out “The Internet of Things (Part 8): Security Vulnerabilities from the OWASP,” (Circuit Cellar 315, October 2016) [5]. Also, the Common Weakness Enumeration (CWE) database [6] maintained by MITRE provides many security weaknesses specifically associated with operating systems. I will be referencing this database throughout this article with the notation CWE-XX. Here are my top three areas that need to be strategically bug free. In my opinion, they need the most attention in the design of the RTOS.
— ADVERTISMENT—
—Advertise Here—
Memory management: It is pretty well known that memory leaks can be exploited and force systems to become non-functional (CWE-401). But these are typically caused at the application level. Nonetheless, any use of dynamic memory in the RTOS must be rigorously tested by analysis and with operational testing to detect memory leaks. And the memory management code itself needs to be as bulletproof as possible.
Buffer management: Buffer overflows are another area that can be exploited (CWE-120). Therefore, all movement of data in and out of buffers must be strategically bug free.
Scheduler: A poorly designed schedular can allow tasks to create priority inversion which, when exploited, can allow an external stimulus to cause the system to lock up and thus malfunction [7].
BEST PRACTICES IN RTOS DESIGN
The RTOS should follow the industry best practices for security where applicable. The following are the ones I deem most important for RTOS design.
Clearing dynamic memory: The RTOS dynamic memory management should clear dynamic memory either when it is released or when it’s created to prevent information leakage between tasks (CWE-226)
Error checking: The RTOS should be designed so that there are no unchecked errors (CWE-391). We once designed the fastest disk defragmenter in the world: Speedback. When we licensed it to an Israeli company, they found scores of places we had unchecked errors. This is best found through code reviews.
Access: The RTOS should have a means for securely identifying and authorizing access (CWE-294)
Multiple Independent Levels of Security (MILS): The RTOS should allow for many different layers of security. All security eggs should not be put into one basket. See my article “The Internet of Things (Part 5): IoT Security,” (Circuit Cellar 307, February 2016 [8]) on the ways to protect a castle: the moat, the wall, the door and, if all else fails, the boiling oil.
Firewall: An RTOS that supports networking should provide a built-in firewall.
— ADVERTISMENT—
—Advertise Here—
Support the use of official encryption certificates: Network communication and secure services should be implemented using standard encryption certifications (CWE-295).
Usage of industry standard cryptography libraries: A robust hashing or cryptographic library should be used.
Memory management units (MMUs): The use of an MMU should be supported in an RTOS if the processor supports it.
Resource throttling: A means like quotas (CWE-770) should be implemented to protect the device from running out of resources. In this way, the RTOS can protect the system from attacks that are outside the typical design envelope.
Support for secure boot loading and execution: The RTOS should provide a mechanism for secure boot loading and execution.
Secure file system: The RTOS should clear unused blocks in the file system when a file is deleted.
Security monitor: The RTOS should provide some mechanism for providing an audit trail for attempted access or actions from the outside world (logins, resource activity).
RTOS updates: As the final line of defense (the boiling oil), the RTOS should provide a secure and verifiable method of being updated. Very few of the 200,000 vulnerable VxWorks systems mentioned earlier have been updated.
DOES FreeRTOS MEASURE UP?
So how does FreeRTOS stack up? Again, as I said last time, we are not trying to make FreeRTOS into a Linux or VxWorks. But does it perform at an acceptable level of security? On the certification front, in January of 2021, FreeRTOS was certified as SESIP Assurance Level 2 compliant [9]. Their certification consisted of testing to a limited set of security requirements derived from the Common Criteria [10]. It excluded tests against physical attacks, insider attacks and limited testing to a system with an MMU. Also, it only tested with one processor: the LPC54018 IoT Module from NXP Semiconductors (Figure 2). Unless you use that processor, a lot of your code is not certified.
NXP Semiconductors’ LPC540XX MCU
In addition, at the end of February of 2021, FreeRTOS was PSA Certified [11] on the PSoC64 Secure microcontroller (MCU) from Infineon Technologies (formerly Cypress Semiconductor). This is another independent IoT security verification framework. The fact that FreeRTOS is ported to devices like the PSoC64, which is hardware certified through PSA, tells us a lot. A dual-core device which includes a core for non-secure processing and one for secure processing, the PSoC64 Dual Core (Figure 3) provides most of the latest security measures built into the hardware, and certified!
PSoC64 Dual Core processor
But is that enough? Let’s look at how it stacks up to our criteria.
Looking at past vulnerabilities: Certainly, in terms of being Strategically Bug-Free, we can look at two things. Looking at the last 10 releases, how many of them have included security fixes. That will tell you a lot about the maturity of its security. Second, we can look at the list of documented vulnerabilities. Table 1 provides a look at the last 10 FreeRTOS releases. Four of the last 10 releases have had security fixes. This is both good and bad. Good that they are being found. Bad in that such a small RTOS should have so many security issues.
Looking at reported vulnerabilities: If we search the NIST database for FreeRTOS, it provides some unsettling results [12]. Prior to being certified, FreeRTOS had some very serious security vulnerabilities. In 2018, Ori Karliner of Zimperium Security Labs uncovered 11 serious security flaws in FreeRTOS+TCP. If you drill down to any of these, you can see the immaturity of the code. A large number of systems were released with these flaws. Thankfully they have been picked up and solved. Table 2 provides a list of the last three reported security vulnerabilities.
Best practices: Finally, how does FreeRTOS stack up to the best practices that I listed earlier. Table 3 provides a list and whether FreeRTOS is compliant with my opinions. With a few exceptions, FreeRTOS has come a long way in becoming an RTOS that is implemented with all of the best practices for creating secure systems.
Listed here are the last 10 FreeRTOS releases. Four of the last 10 releases have had security fixes.
FreeRTOS security vulnerabilities
Best practices compliance
CONCLUSION
Most of the security provisions for embedded systems that we design are found in FreeRTOS. But building a secure embedded system with any RTOS is not for the faint of heart. We have looked at few but only in thin slices. Next time, in Part 7, we will look at FreeRTOS+TCP.
— ADVERTISMENT—
—Advertise Here—
RESOURCES
References:
[1] For more about phone phreaking see: https://www.theatlantic.com/technology/archive/2013/02/whatever-happened-to-the-phone-phreaks/273332
[2] For more on this see: https://www.atlasobscura.com/articles/capn-crunch-whistle
Also find out how Captain Crunch was instrumental in launching Apple.
[3] For a high-level review of the Stuxnet worm hack, see:
https://www.businessinsider.com/stuxnet-was-far-more-dangerous-than-previous-thought-2013-11
[4] This is the website of the company that uncovered the 11 vulnerabilities in VxWorks. https://www.armis.com/research/urgent11
[5] See Bob’s article from Circuit Cellar Issue 315 from October 2016 Internet of Things series: “Security Vulnerabilities from OWASP”. The OWASP Foundation maintains a list of the top ten vulnerabilities for Web based devices. https://owasp.org/www-project-top-ten
NIST maintains one list of existing vulnerabilities in real systems at https://nvd.nist.gov/vuln/full-listing
[6] MITRE maintains a Common Weakness Enumeration list to identify common software security weaknesses. https://cwe.mitre.org
[7] “An Analysis of Embedded Software Vulnerabilities and Related Security Solutions” https://kth.diva-portal.org/smash/get/diva2:1149047/FULLTEXT01.pdf
“Depending on the scheduling policies used by the OS, an attacker could lead low-priority tasks to steal execution time of higher priority tasks.”
[8] See Bob’s article “The Internet of Things (Part 5): IoT Security,” (Circuit Cellar 307, February 2016)
[9] Based on the Common Criteria, the Security Evaluation Standard for IoT Platforms provides a set of tests for evaluating how secure a software system is. See https://www.freertos.org/2021/03/why-sesip-certification-for-freertos-matters.html
[10] See Bob’s Circuit Cellar article from August 2018 (Issue 337) “Internet of Things Security Part 4” where he introduces Common Criteria
[11] https://www.psacertified.org/products/freertos
[12] https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=FreeRTOS&search_type=all
FreeRTOS | www.freertos.org
Infineon Technologies | www.infineon.com
NXP Semiconductors | www.nxp.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • OCTOBER 2021 #375 – Get a PDF of the issue
Sponsor this Article
Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org
