16.01.2023

Why low-level code has become the new focal point of cybersecurity for embedded systems

The rapid expansion of connected devices and applications poses cybersecurity threats for embedded systems, download the free white paper to learn about the risks and possible solutions

From smartphones to gaming consoles, automobiles to self-service fuel pumps, medical implants to smart-home technologies, the number of connected devices that touch our lives and make up the Internet of Things has grown rapidly in the past decade. That growth will likely continue for years.

This post is Part 1 of a 3-part series derived from TrustInSoft’s latest white paper, “From Bare Metal to Kernel Code: How Exhaustive Static Analysis Can Guarantee Airtight Security in Low-level Software and Firmware” To obtain a FREE copy, CLICK HERE.

According to IoT business intelligence provider IoT Analytics, worldwide IoT connections were up 8% in 2021 and were expected to grow by 18% in 2022. The firm has forecast that this expansion should continue for the foreseeable future, as illustrated in Figure 1.[1] Such growth will continue to create new opportunities and benefits for technology providers and consumers.

Source: State of IoT 2022: Number of connected IoT devices growing 18% to 14.4 billion globally, IoT Analytics.

Unfortunately, this ever-expanding web of interconnected devices is also creating a serious security challenge for the technology industry.

The low-level code in these devices—the code that interfaces directly with the hardware, like operating system kernels, device firmware, drivers and controllers—is, along with the hardware itself, the foundation of cybersecurity.

These low-level layers in the firmware/software stack have access to both the hardware below and the application layers above. If they aren’t secure then neither is anything that sits on top of them.

Coding flaws in low-level code create vulnerabilities that hackers exploit. Once hackers gain access, they can either take control of the device or access the data stored within. For owners of these devices that could mean the theft of their sensitive data—possibly their bank or credit card information. In the case of safety-critical systems like automobiles and medical devices, the result could be the injury or death of passengers or patients, product recalls, lawsuits, and other losses.

Verifying that low-level code is free from vulnerabilities is a serious challenge.

An inviting target for hackers

Because low-level code offers access to both the hardware below and the high-level code above, any flaws in it make inviting targets for hackers. Exploits against those flaws could cause the hardware to crash or allow the attacker to gain control of the high-level code.

A global security survey conducted by Microsoft found that 80% of enterprises have experienced at least one firmware attack in the past two years.^[2] Meanwhile, the National Institute of Standards and Technology’s (NIST) continually updated National Vulnerability Database (NVD) has shown a better than five-fold increase in firmware attacks since 2017.^[3]

“These attacks are of particular importance,” says firmware and hardware protection firm Eclypsium, “because they enable attackers to gain fundamental control of enterprise devices, subvert security controls, and persist invisibly, undetected by traditional security solutions.” ^[4]

Operating systems are even more cybersecurity-critical. They have far greater reach than firmware. An OS has access to every application that runs on top of it. If the OS is compromised, all those applications could be compromised as well. For this reason, Microsoft has called the OS kernel “an emerging gap in (cybersecurity) defense.”

The following example illustrates just how dangerous that gap can be.

In 2017, Wikileaks revealed that the CIA had “weaponized” numerous zero-day vulnerabilities in iPhones, Google Android, Microsoft Windows, Samsung smart TVs, vehicle control systems, and other devices. These were vulnerabilities they had either discovered, developed, obtained from other agencies, or purchased from cyber arms contractors.

A zero-day (or 0-day) is a software vulnerability previously unknown to those who should be interested in its mitigation, like the software vendor. Until the vulnerability is mitigated, hackers can exploit it to adversely affect programs, data, additional computers, or a network.

Wikileaks also revealed that the CIA had subsequently lost control of its zero-day exploit arsenal through unauthorized circulation among former government hackers and contractors. That arsenal had thus become available to hostile governments, cyber mafia, and malevolent hackers worldwide. Until all those target zero-days are mitigated, millions of devices are at risk.

In order to reduce such risks, some OS designers adopt modular architectures, using hypervisors for example. Because you have several operating systems running in parallel but isolated from one another under the supervision of the hypervisor, modularity can limit the spread of a malware infection and keep your system running.

That type of risk reduction, however, can only go so far. If there are exploitable flaws in your hypervisor, such security measures could all be for naught. Far better to have no zero-day vulnerabilities whatsoever in your code.

Embedded systems (and businesses) at high risk

According to the consulting firm RSK Cyber Security, embedded systems are particularly prone to cyberattacks.^[5]

For businesses, this can present a serious risk, as these devices are directly interconnected with the core network of the company. A coding error in an embedded device can provide an avenue for an attack on the enterprise as a whole. The flaw not only compromises the device; it could take down the company’s entire network.

There are several reasons embedded systems are so susceptible. First, they can be attacked through vulnerabilities on two fronts, through both the hardware and the code (software and firmware). Second, integration with the IoT (connectivity) increases the number of attack vectors.

“Another reason is stuffing a small embedded system with many functionalities leads to a lack of security by design,” says Praveen Joshi of RSK Cyber Security.^[6]

To save memory space and limit power consumption, developers of these embedded applications often resort to non-standard coding structures. While done out of necessity, this practice results in optimized code that makes bugs hard to find.

Common vulnerabilities in low-level code

Many attacks on embedded systems target vulnerabilities caused by bugs in low-level code.

One of the most common types of attacks against embedded firmware and software targets a coding error vulnerability known as memory buffer overflow. This software weakness was ranked #1 on the CWE Top 25 2019 list.^[7] It typically ranks highly from year to year and is most prevalent in the C and C++ programming languages.

“In this type of attack, hackers exploit the system vulnerabilities to swamp the device’s memory,” says Joshi. “Attackers manually fill the memory buffer allocated to contain the moving data inside the embedded systems. The OS of the embedded system will attempt to record some data in the memory section next to the buffer. But, eventually, it will fail.” ^[8]

Other dangerous undefined-behavior vulnerabilities include:

Integer overflow errors
Integer underflow errors
Buffer overwrite errors
Buffer overread errors
Null pointer deference errors

How can software development organizations protect their products against such exploits?

We’ll look at what doesn’t work and then what does work in our upcoming posts in this series.

In our next post…

In Part 2 of this series, we’ll examine the limits of traditional static analysis and software testing for removing security vulnerabilities from low-level code.

We’ll conclude the series by examining why exhaustive static analysis—the method employed and automated by TrustInSoft Analyzer—is ideally suited to ensuring the security of low-level code.