Table of Contents:

Safeguarding LYNX MOSA.ic: Lynx and RunSafe’s Security Partnership

Why does memory safety matter to Lynx users?

No impact on Runtime performance? Development schedule?

Easier compliance with security requirements

What about the Software Bill of Materials?

How to immunize LYNX MOSA.ic against 70% of code vulnerabilities?

Safeguarding LYNX MOSA.ic: Lynx and RunSafe’s Security Partnership

RunSafe Security is excited to announce a strategic partnership with Lynx Software Technologies (Lynx). The partnership between Lynx and RunSafe protects LYNX MOSA.ic against 70% of the most common vulnerabilities with no developer impact.

At the launch of the partnership with Lynx Software Technologies, the RunSafe protection applies to the build root Linux operating system, applications, and customer software. In early 2024, the team intends to release the LynxOS-178 version of the protections. 

The segments, including aircraft manufacturers, industrial controls, defense systems, and IOT devices, are really challenged with meeting desired delivery schedules at a time when system complexity is increasing at a fast rate. Our effort here with Lynx is beyond “marketecture” and PowerPoint. The purpose of this engagement is to deliver RunSafe technology as a proven component in LYNX MOSA.ic. The “ic” stands for Integration Center and we fully believe that one critical piece in enabling reductions in program risk and development schedule comes from integrating cybersecurity protections during the product development process. Lynx will deliver RunSafe’s technology as part of its LYNX MOSA.ic product.

Why does memory safety matter to Lynx users?

Prevalence of Memory Safety Bugs

In compiled code, memory safety bugs are the single largest class of bugs. In the embedded and real-time operating system spaces, compiled code represents the vast majority of code. A few statistics, based on research at North Carolina State University:

• Typically 70% of the bugs in compiled code are memory safety issues.
• Memory safety bugs have a much more severe impact on systems, according to their average severity scores (NVSS). 
• 59% of memory-related code vulnerabilities have been weaponized, with exploits readily available. 
• Memory safety bugs tend to take much longer for developers to fix, relative to non-memory safety bugs (180 days for memory safety vs 90 days for non-memory safety).

Patching Deployed Systems is Difficult

Time is on the side of the attackers. Deployment cycles of systems in military, aerospace, and federal markets are long. In the case of planes, they can be measured in decades. Patches are hard to deploy to these complex, fielded systems. Meanwhile, highly resourced and skilled attackers develop cyber kill chains, finding (or buying on the dark web) zero days. With RunSafe, systems running Lynx RTOS are protected and future-proofed against the majority of these zero-day attacks without patching.

Regulatory Drivers

For those Lynx customers selling to US government programs, there is an increased focus on the memory safety of acquired systems and software. Figure 1 below shows actions undertaken by the US government to tighten up memory safety.

No impact on Runtime performance? Development schedule?

The process of reordering the functions happens when the process is set up in memory. Instead of jumping right to the normal entry point for the function, the binary reorders its functions first. Then it begins normal operations. This reordering of memory typically adds only 1%-3% to process setup time. If a function took 1 second to load before, it will now load in 1.01 to 1.03 seconds.

From that point forward, the RunSafe protection is passive. There is no change in the sheer instruction count, control flow, etc. There are no additional memory reads, writes, lookups, etc. Our customers, even on the most stringent real-time systems, have never found a measurable impact on runtime performance.

Easier compliance with security requirements

Lynx customers are better able to document their compliance with RMF (DoDI 8510.01), which incorporates NIST 800-53. Consequently, programs accelerate time to ATO at a lower cost. For high-impact systems, RunSafe enhances compliance with more than 20% of the controls. For many RunSafe-impacted controls, the only alternative is thousands of hours of testing. 

RunSafe provides “last-mile integrity” into the running memory, increasing confidence that the code operates in memory the way the developer intended. By mitigating an entire class of vulnerabilities, RunSafe makes possible incident handling responses that were previously impossible. This protection can be applied to every layer of the system’s software. Table 1 shows the breakout of impacted controls across the various levels of system integrity. A whitepaper with more details about the NIST 800-53 controls can be found here.

What about the Software Bill of Materials?

Machine-readable SBOMs are being required by EO14028 and making their way into FAR clauses. RunSafe’s tools make it possible to build a complete and perfect SBOM for each Lynx project, regardless of whether a package manager is used for the compiled code, or not. By working into the build process, RunSafe is able to identify every file coming into the build, every dependency, library, include file, etc., and build a perfect tree of dependencies between the components. For Lynx Software Technologies customers, this is a zero-effort activity.

How to immunize LYNX MOSA.ic against 70% of code vulnerabilities?

A future webinar and configuration document will describe the configuration steps, but this would involve a slight change to a build script, instructions on where to include the license key, and which configuration files to edit. No other changes are necessary (see figure 2).

How does RunSafe Security Code protect the OS and applications?

Memory safety bugs (stack overflows, heap overflows, etc.) wreak havoc on their targets by using code already in memory in unintended ways. For example, by moving the instruction pointer one byte past an add instruction, the processor may execute a branch instruction. For these attacks to work, the attacker must have highly predictable insight into the layout of memory on the victim process.

Figure 3 below shows a few different memory scenarios. The first column is the memory layout if no protection is applied. This gives the attacker a perfectly deterministic layout across all devices. The second column shows the protection of a technique called Address-Space Layout Randomization (ASLR). This randomizes the base address of binaries or libraries, but t威而鋼
he body of the binary will still have a deterministic organization, relative to this base address. Given the prevalence of memory leaks, ASLR hasn’t done much to slow down attackers in the last 15 years. RunSafe’s protection randomizes the individual functions that comprise a binary, as shown in the Fine-grained randomization graphic.

On average, binaries tend to have around 280 functions. That gives our attacker roughly 280(!) permutations to consider. To understand that scale, if an attacker were able to attempt 100 trillion possible randomizations every nanosecond, the attacker would spend 3*10524 universes before they hit every possible permutation.

After analyzing thousands of binaries and hundreds of thousands of functions using open-source software, RunSafe Security was able to show that there weren’t enough bits of code to misuse at a function-level, to create attacks that work on unprotected code.