Get Along Little Dogies

Manuals

White Papers

	Home > Library > White Papers

Get Along Little Dogies

by Ralph Moore
March 2024

Is it time to herd your CWEs (Common Weakness Enumerations) into a safe coral where they won't trample your code? In a recent report, 918 CWEs have been identified and documented by MITRE, and more are being identified regularly. Of these, 418 are classified as software weaknesses. Each weakness is described in a separate document, which also discusses its impact and likelihood and provides examples of the weakness. Granted there are tools, such as static analyzers, and standards, such as MISRA, that are intended to help programmers avoid these weaknesses in their code. Nonetheless, this is an awful lot of information to be concerned about when a programmer is trying to create and debug software that does something useful.

The Battleground

When issuing his recent Executive Order on Improving the Nation's Cybersecurity President Biden declared that there is now "a war on cyber-attacks". Currently, most high-profile attacks seem to be picking the low-hanging fruit of phishing, using default passwords, software supply chain attacks, and similar attack surfaces. However, the nationwide mobilization spurred by the Executive Order is likely to prune this low-hanging fruit. As it starts to disappear, hackers are likely to move more to device vulnerabilities (i.e. CWEs). Currently it is reported that hundreds of thousands of device attacks occur every year and that the frequency of these attacks is increasing exponentially, as is the damage caused by them. Despite this high number, it is probable that a majority of device attacks are not reported. After all, why should an OEM publicize that its device is not secure?

However, due to the Executive Order, this landscape is about to change. The order elevates device integrity as a major element in its focus on Zero Trust Architectures. A major element of this is the requirement for Software Bills of Materials (SBOM) for all systems purchased by the Federal Government. No longer can weak software hide in obscure devices within large systems. This requirement recognizes that hackers will find these devices and exploit them. A day of reckoning is coming for OEMs who wish to do business with the Federal Government — they must up their game. The question is what is the best way to do so?

The Lure of Secure Code

There are many tools, such as static code analyzers, that are aimed at finding bugs and security weaknesses in software and that are aimed at enforcing good coding practices. There is no doubt that diligent use of these tools will produce better code and may even reduce development schedules.

Nonetheless, use of these tools is a distraction from the work at hand. Is a developer's primary job to produce secure software, or is it to produce software that accomplishes something useful? Even without the code-quality distraction, most projects run over schedule and over budget, and many are ultimately cancelled for these reasons. Hardware complexity has become so great that developing reliable device drivers has become a gargantuan effort, in many cases. Similarly with many protocols and other software. Even more complexity (e.g. AI) is "moving to the edge". It would seem that current programmers should be lauded for accomplishing something that works at all, even if it is full of security flaws and latent bugs!

There are also other problems with the secure code goal:

Software, alone, cannot create strong security.
The "better lock" argument — how do you know how much to spend on the lock? Did the programmers of the HVAC software hacked in the Target break-in think a good lock would be worth millions? ($220 million, to be exact.)
The number of CWEs is increasing rapidly. It seems unlikely that software tools and programmers will be able to keep up.
Given that hackers are continually finding new vulnerabilities, it may not even be theoretically possible to create secure software.

Ref 4 studies the current problem implementing secure embedded systems. It concludes that security-aware developers are in short supply. A large part of the document, thereafter, is aimed at improving secure code training. An alternate thesis is that good programmers create good code, poor programmers don't, and good programmers have always been in short supply. Partitioning offers project managers an alternative to finding super programmers: partition systems such that critical functions are isolated from less-critical functions. Then put the good programmers to work on the critical partitions and the less-good programmers to work on the other partitions. This is more pragmatic than wasting time training people who will never become stellar programmers.

The Partitioning Solution

SecureSMX® provides a methodology to move the most vulnerable code into isolated partitions from which a hacker cannot reach the rest of the system, as shown below:

In this figure, App1 and App2 could be vulnerable application partitions, and Middleware is a vulnerable partition. App3 has mission-critical code, and Security is the only partition allowed access to the Vault where the gold and jewels are stored. Ref. 1 covers isolating a TCP/IP stack with an Ethernet driver, and Ref. 2 covers isolating third party software, which may be of questionable quality (i.e. SOUP). The premise is that certain parts of the system are more vulnerable than others and that rather than trying to fix them, it is just as effective and much easier to isolate them. This is especially applicable to existing systems. For new systems, the SecureSMX methodology provides a clear path to partitioning the whole system (see Ref. 3).

Doing static analyses and running other tests is still a good idea because it makes the hacker's job harder. But because hackers are very smart people, and if the reward is high enough, good code is not going to keep a hacker out. Recognizing this inevitability, it makes sense to divide the code into isolated partitions so that the hacker cannot access code and data in partitions, other than the one he has just broken into. The partitioning enabled by SecureSMX is hardware enforced and thus virtually unbreakable with malware, alone.

The most secure partitions are those running in umode (unprivileged or user mode). pmode (privileged or protected mode) partitions provide less security, but may be useful for legacy code, especially mission-critical code that no one wants to touch.

Downsides to Partitioning

In addition to being a methodology unfamiliar to most programmers, umode partitioning does have its downsides:

System services require a software interrupt (SWI) interface, and thus are slower.
Many system services are restricted or limited, for security reasons.
The user may need to add his own system services. This requires writing simple shell functions and adding addresses to a jump table.
Full isolation requires converting function-call APIs to message APIs. While the code to do this is simple, performance is moderately impacted. Debugging is also more difficult because caller and callee are in different tasks thus breaking the call stack.
Interrupts cannot be disabled in umode. However, it is possible to mask selected interrupts to protect critical sections.
Initially debugging is more difficult because Memory Manage Faults (MMFs) occur unexpectedly. Eventually these become just another tool to help find bugs.

Mostly, partitioning requires learning a new methodology. Once learned, the impact upon development time is minimal — far less than the pursuit of perfect code.

How Partitions Protect

In this section we cover a few common hacking techniques and show how partitioning with SecureSMX blocks them. In general, however, partitioning aims to contain hacks and does not directly prevent them. In those cases, hacks cause MMFs, which result in the current task being stopped and the partition or the whole system being rebooted, in order to evict the hacker. In addition, many CWEs are above the software level and thus partitioning may not help with them. On the other hand, partitioning may protect against as-yet-undiscovered CWEs.

Code Injection Attacks

Typically a hacker is able to conceal his malware in some third-party software or in a software update. In another hack, he overflows a buffer in the current stack with the address of his malware until a valid subroutine return address is overwritten in the stack. Then, when the task returns from that subroutine, control goes instead to the malware. SecureSMX protects against this as follows: If the malware is not in a current MPU region, an MMF will immediately occur. If the malware is in a current MPU region, the malware will run, but it cannot access anything outside of the current partition's regions. If it attempts to do so, an MMF will occur.

Otherwise the malware is limited to damaging the current partition. It might attempt to damage other partitions by sending invalid data or commands to them. Therefore, the software in all partitions should be checking the validity of data and commands that it receives from other partitions. The malware could attempt to call system services that damage the system. However, such services are not permitted in umode; though they are permitted in pmode, pmode is especially hard to penetrate.

As apparent from the above description, partitioning is not a complete solution, but rather a foundation for strong security solutions. It is still necessary to write prudent code that checks parameters it receives, checks return values for routines that it calls, etc. However, super-human code is not required.

Return-to-libc Attacks

This is basically the same attack. It is so named because instead of branching to malware, it historically has branched to a C library function that causes damage. But it can also branch to an application function, which if called inappropriately and with incorrect parameters can cause damage. In the former case, damaging C functions should not be used in embedded systems. In the latter case, damage is limited to the current partition. Of course, if damage is possible to whatever this partition controls outside of the embedded system, then those functions must be carefully written.

Examples from CWE Top 25 Most Dangerous Software Weaknesses

CWE-787 Out-of-bounds Write and
CWE-125 Out-of-bounds Read

Writes and reads are limited by a task's regions. If a region boundary is exceeded, an immediate MMF occurs, the task is stopped, and recovery software begins running. The recovery software is likely to shut down the partition containing the task and reboot it, thus evicting the hacker. Whatever the partition was doing may be lost, but the system can continue operating. Since mission-critical partitions operate below the pmode barrier (see Fig. 1) or are in isolated umode partitions, this means that they are not impacted, and the system continues doing its main functions while the invaded partition is fixed and restarted.

CWE-416 Use After Free

SecureSMX provides customized heaps for partitions that need them. A partition's heap is part of one of its data regions. Use-after-free causes damage only within the current partition because no other partition uses the same heap. (If another partition needs a heap, it is given its own heap.) SecureSMX also allows protected blocks to be allocated from heaps outside of the current partition. A protected block has a region of its own that is loaded into a spare slot in the MPU. When freed, the MPU slot is cleared. Thus use after free is not possible for protected blocks.

CWE-476 NULL Pointer Dereference

Causes an immediate MMF.

CWE-94 Improper Control of Generation of Code ('Code Injection')

Discussed above.

CWE-269 Improper Privilege Management

Assignment of tasks to umode or to pmode is performed in pmode prior to task launch and cannot be changed from a task running in umode.

Conclusion

SecureSMX provides a complete methodology for achieving fully isolated partitions in MCU-based systems. It does not solve all security problems. However, we believe that it goes a long way toward achieving security for such systems and that it constitutes a pragmatic base for the design of secure MCU-based systems.

References

1. Ralph Moore, Where's The Gold?, March 2024.
2. Ralph Moore, What's In Your Soup?, March 2024.
3. Ralph Moore, Moving Uptown to Umode, March 2024.
4. Secure Code Warrior, Shifting from reaction to prevention: The changing face of software security, 2021.

Ralph Moore is President of Micro Digital. A graduate of Caltech, he has served many roles at Micro Digital since founding it in 1975. Currently he is lead architect and programmer for SecureSMX.

More Solution Papers

Home Sitemap Contact