Security fundamentals for embedded software

David Kalinsky

March 24, 2012

David Kalinsky

What's a software developer to do?
During embedded systems software design, you can enhance software security by keeping several fundamental ideas in mind:²

Mindframe #1: Distrustful decomposition
Separate the functionality of your software into mutually untrusting chunks, so as to shrink the attack windows into each chunk. (In embedded software, we sometimes call these chunks processes or subsystems or CSCIs.)

Design each chunk under the assumption that other software chunks with which it interacts have been attacked, and it is attacker software rather than normal application software that is running in those interacting chunks. Do not trust the results of interacting chunks. Do not expose your data to other chunks via shared memory. Use orderly inter-process communication mechanisms instead, like operating system message queues, sockets, or TIPC (Transparent Inter-process Communication). Check the content you receive.

As a result of mutually untrusting chunking, your entire system will not be given into the hands of an attacker if any one of its chunks has been compromised.

Mindframe #2: Privilege separation
Keep to a minimum the part of your code that executes with special privilege.
Think about it for a moment: If an attacker succeeds in breaking into software that's running at a high level of privilege, immediately your attacker will be operating at a high level of privilege too. That'll give him an extra-wide open "attack window" into your system.

So let's avoid running application software in kernel mode, or master mode, or supervisor mode, or whatever your particular CPU architecture may call it. Leave that mode for operating system use only. Run your application software strictly in user mode. This will enlist your CPU hardware in efforts to limit your software's attack window.

Mindframe #3: Clear sensitive information
Clear every reusable resource when freeing it.

Think about it: After you've released the resource, be it a RAM buffer or a software-hardware interface data register, the next user of the very same resource might be an attacker. Embedded system attackers enjoy "phishing" these resources, just as much as Internet attackers enjoy phishing. Wouldn't they be overjoyed to read whatever data you had been working on in the buffer, or to read the data you've just given to hardware for output!

Most resource release services in embedded environments simply mark the newly freed resource as "available." They leave the old information contained in the resource potentially visible to new users, trusting the new user to over-write the old content rather than reading it. This is done since it's much faster than explicitly nulling out the resource.

So when an application is done with a resource, it's up to the application to prepare for releasing the resource by first zeroing out each and every:

•    Heap buffer, memory pool buffer, memory partition segment.
•    Statically-allocated memory buffer.
•    Released stack area.
•    Memory cache.
•    File in a file system.
•    Hardware interface data register, status register, control register.