The yocto project is a game-changing developer environment that streamlines the creation of custom embedded linux distributions for any hardware architecture. yocto uses “layers” and “recipes” to provide easy configuration management and a reliable and reproducible build process. This toolchain has opened the door to inserting security easily into the build process, reducing operational burdens downstream while increasing protection from cyberattacks for software built with yocto.
Because the images running on each yocto-built embedded system are identical, a single vulnerability can expose thousands of systems and attackers can easily scale their attacks. Alkemist can mitigate this concern by using a patented technique called Loadtime Function Randomization (LFR). Alkemist performs randomization at runtime instead of buildtime, preserving “Binary Reproducibility,” one of the yocto project’s core features, while dramatically increasing security against memory-based attacks.
Modify Memory Layout – Stop the Attack
In a memory corruption-based exploit, attackers hijack legitimate code to achieve unintended, attacker-derived outcomes. Attackers utilize buffer overflows, stack overflows, heap overflows, use-after frees, etc. to redirect execution to targets of their choice, much like creating a ransom note from the letters cut out of a magazine.
Defenders have used randomization methods to defend against these attacks for many years, including tools like Address Space Layout Randomization (ASLR), which comes with many modern operating systems. Unfortunately, as demonstrated by countless anecdotal examples, ASLR does not provide sufficient randomization to defeat modern advanced attack methods. (Fig. 1). RunSafe’s Alkemist expands the concept to a much more powerful level of effectiveness, delivering orders of magnitude greater memory location entropy without sacrificing performance or ease of application.
The problem with ASLR is that it doesn’t provide enough granularity to defeat hackers. ASLR randomizes the location of code and data sections in memory. While the location of code is randomized, the order of that code is always the same from system to system, program launch to program launch. As a result, a single information leak can give attackers all the information they need to stitch together a reliable and effective exploit.
Figure 1: Memory Diversity
Alkemist’s Load-time Function Randomization (LFR) technology efficiently creates much greater memory diversity by restacking functions in memory, before a process begins executing, every time that process executes. The right two columns of Figure 1 show the diversity levels created by ASLR and LFR.
LFR restacks the memory by adding a small stub into the binary (or shared object) at compile time and statically linking LFRLib.so, which provides the routines for randomizing and patching function locations (Fig. 2). Once the patchups are done, normal execution resumes. This setup adds about 1-3% to process setup time, and doesn’t impact runtime performance at all.
Figure 2: LFR Process Setup
Operating Benefit 1 – Reduce customer wear, tear, risks, and costs
The yocto project’s thriving community deploys bug fixes and CVE patches rapidly. Despite this, many devices are deployed in environments where systems are difficult, if not impossible, to update. According to a recent IIoT World survey, 43.8% of Enterprise IoT customers spend more or much more time on security alerts, patches, and incidents related to IIoT devices than their IT, meaning that IoT is causing significant customer pain. With 50%-70% of patches being driven by memory corruption related issues, technology like Alkemist’s will allow those customers to dramatically reduce the urgency and frequency of updates and patching.
Operating Benefit 2 – Maintain product velocity, without sacrificing security
The product schedule can never afford all of the testing that could be done. How much testing is enough to give the product manager and customers confidence that it was “enough?” What testing
got left off? Which code paths? Which of the many potential bug reports weren’t fixed before the code freeze date arrived? With LFR applied, product managers can move forward confidently knowing that the most insidious strains of vulnerabilities have already been mitigated, even before they were identified in a test. When testing identifies issues in fielded systems, those patches can be rolled into a normal, sane patch release cycle, without stressing your product teams or customer support teams.
3 Steps, 5 Minutes: Memory Corruption Immunized
The procedure is as follows:
- Download LFR layer tarball from RunSafe Security
After registering at alkemist.runsafesecurity.com and getting a license key, you will be able to download the tarball containing the LFR yocto layer (Self service downloads are coming soon. Please email support@runsafesecurity.com to get a yocto layer tarball sent to you). - Extract tarball onto yocto build system
Run tar -xzf meta-lfr.tgz. to unpack the tarball onto the build system. Note the location where the layer is extracted. - Modify bblayers.conf
Add the path to the LFR layer to the list of layers in conf/bblayers.conf — Figure 3 shows the exact addition to bblayer威而鋼
s. This layer makes the following changes to the build process:
-Inherits the selfrandomize class to all recipes
-Prepends the path to custom LFR build tools
-Adds necessary compiler flags
-Adds necessary linker flags.
After installing the layer the yocto build commands can be run as normal and LFR will be applied to the compiled binaries.
Figure 3 – Example bblayers.conf file
Summary
To maximize IIoT device profitability and customer satisfaction, users can take a few simple steps to augment yocto’s robust platform with tooling to increase security and decrease update frequency, while still maintaining aggressive delivery timelines. yocto is quickly becoming the de facto standard build environment for embedded devices. Its configurability and wide range of supported hardware and software target systems make it ideal for fine-tuning binary images to meet exacting processing, memory, and power constraints. yocto’s strength in enabling custom distributions of thousands or even millions of replicated device images, however, comes with costs in terms of security exposure and management. The yocto community is highly responsive in providing patches, but most customers want more assurances when making a bet on their company’s reputation.
RunSafe provides a simple and seamless option to completely eliminate zero-day and other memory-based vulnerabilities, without patching, for yocto developers. With a 5-minute one-time implementation into the native yocto build stage, RunSafe’s Alkemist technology immunizes binaries from memory attacks, so that every image is functionally identical but logically unique. This changes hacker economics back in favor of the manufacturers and users of embedded devices.
You can get started today by registering at alkemist.runsafesecurity.com.
IIoT World editor-in-chief Lucian Fogoros recently interviewed RunSafe Chief Technology Officer Doug Britton and Andrew Murray, QA Ninja about the impact of the yocto project, the rising number of vulnerabilities in the IoT industry and effortless way adding Alkemist to a yocto project eliminates those vulnerabilities.
https://youtu.be/vSIgC-W0VtI
