Back to the Overview

Embedded Linux Security with Address Space Layout Randomization (ASLR)

– ELinOS, Linux, Security

There are many ways how assets are threatened and many ways how to defend them. In some cases, security paradigms are heavily disputed for example the approach to achieve security by obscurity which means that the way how a system works is kept secret. Also, virtualization isn’t commonly agreed upon to be a valid paradigm since attackers can seek for ways to break out. There is no royal road in cyber security, but it helps if you are actively mitigating security issues (what might look self-evident but isn’t quite often in the field of embedded systems). Nevertheless, there are assets to defend, which most experts in the field of security can settle on.

These assets are authentication mechanisms, code (and system) integrity, non-repudiation, availability and confidentiality. One of the most common security issues in the embedded world are buffer overflows which threaten assets in multiple ways. For example, in embedded systems without a concept of user account separation, buffer overflows will usually mean that a successful attacker will immediately gain root privileges on the device. 

SYSGO Quotation

"Embedded systems are pervasive, handling an ever-growing range of functions before granted to simple electronic devices, operating on the physical world while connected to the internet.

Now complete systems operating multiple mixed-critically tasks on a single hardware platform, they nonetheless often lack the simplest security measures. For example, thousands of IP cameras where easily hacked and further used as a botnet, as they would all share the same weak administrator password.

Failing to validate input data may allow an attacker to bypass the intended process isolation the OS is supposed to enforce. ELinOS is thoroughly coded and reviewed so that vulnerabilities based on buffer overflows are avoided. In addition, randomization of the kernel and user address space layout is one of the universal countermeasures implemented in ELinOS that helps prevent an attacker from reliably jumping to a chosen useful location even if a successful buffer overflow could be mounted, thus making the exploit useless."

~ SYSGO Security expert Guillaume Fumaroli

When you think of buffer overflows, there are several ways to mitigate. First of all, this is a matter of programming language since some of these come with issues that weren’t properly thought of when they were invented in terms of security. In C – commonly used for programming embedded targets – memory corruption is a quite usual attack vector. Using C/C++ isn’t necessarily problematic, but you have to thoroughly validate your code. Of course, you can use programming languages, that prevent problems like these: For example, Rust: Its paradigm (so to say) is to disallow risky programming styles. In terms of buffers, Rust comes with automatized memory management that prevent exceptions such as overflows. Rust checks array length and if it is smaller than the index you are addressing then Rust will deny to proceed. Mechanisms like these close the door for programmatic negligences when attackers are looking for associated buffers to overflow.

Another technique that mitigates memory corruption is space layout randomization (ASLR). The main idea is to randomize the sections (i.e. the address ranges where code and data are located) in the virtual memory of a process. This means that buffer overflows can still be triggered. However, an attacker will typically use an overflow as a means to redirect program execution to a desired memory address, where the “payload” of the attack is located. Hackers have thought of ways to bypass this by techniques such as spamming the payload repeatedly (called heap spraying) thereby increasing the chance to execute malicious code after all. Nevertheless, ASLR is a state-of-the-art mitigation technique and a massive security improvement, particularly for IoT devices.

The Linux kernel implements ASLR since 2005 partially and since 2014 KASLR – a kernel adaption of it. You can check if the Linux kernel on your target can use ASLR on the console:

$ cat /proc/sys/kernel/randomize_va_space

There are three possible outcomes. 0 means ASLR is disabled while 1 and 2 states ASLR is activated. While 2 says it is fully activated, 1 tells you ASLR uses conservative randomization. This comprises randomization of shared libraries, stack, mmap(), virtual dynamic shared objects (vDSO) and heap. Full activation is when memory management through brk() is also randomized.

For the unlikely case ASLR is deactivated you can easily change that in the console:

$ echo 2 > /proc/sys/kernel/randomize_va_space

Enabling the kernel option is only one part. For full ASLR mitigations in your application you have to make sure it has been compiled as Position Independent Code (PIC/PIE). Thus all sections of the code will be loaded at random locations.

Starting with ELinOS 7.0.2 the compiler automatically enables Position Independent Code when compiling an application. The pre-compiled applications provided with ELinOS are already position independent.

SYSGO’s ELinOS comes with the ASLR mitigation and comprises a security philosophy of a lean system. This means its paradigm is to have the smallest possible attack surface while ensuring all functionality is given. User and kernel space can be conveniently configured in the short and beginner friendly setup process.

Learn more at www.sysgo.com/elinos

Back to the Overview

aslr, attack, iot, kernel, randomization, security

Useful Links