The Fix: Patching Embedded Systems

Tuesday, November 24, 2020

The need to patch a problem in a program that is embedded in an existing system, perhaps to introduce or enhance security, is a common one, says UC Santa Barbara computer science professor Giovanni Vigna. “But, why would you do that?” he asks rhetorically. “Why not just write a different program?” 

“Because, sometimes, it’s not possible, or it would require a very substantial effort,” he answers. “Sometimes, you’re given a program to patch, and you don’t’ have the source code to modify it at that level and recompile it.”

“Many embedded computer systems, such as those in trucks, airplanes, and medical devices, run on software for which the source code and the original compilation toolchain are unavailable,” says Antonio Bianchi (PhD ’18), an assistant professor at Purdue University who studied in Vigna’s lab at UCSB. “Many old software components running in these systems are known to contain vulnerabilities, but patching them is not always easy or even possible.”

Vigna, director of the Center for CyberSecurity at UCSB, and Bianchi are among a group of researchers at UCSB, Purdue, and the Swiss Federal Institute of Technology Lausanne (EPFL) who have received a four-year, $3.9 million Defense Advanced Research Projects Agency (DARPA) grant to fund a project called “Assured Micropatching,” aimed at improving the process of patching code in vulnerable embedded systems.

“Without source code, patching a vulnerability necessitates editing the binary code directly,” says Bianchi. “Additionally, even in a system that has been patched, there is no guarantee that the patch will not interfere with the original functionality of the device. Because of these difficulties, he said, the code running in embedded systems is often left unpatched, even when it is known to be vulnerable.”

Given that situation, Vigna explains, “You need to look at the program in a different way; you need to look at the binary code, the machine code, the ones and zeroes that actually determine the behavior of a program. But, until recently, binary programs were largely considered static; that is, once you had a compiled program, the thinking went, the program could not be changed. Interestingly enough, in the past, it was often only malicious actors who would focus on modifying binaries to infect benign binary programs.”

But in the evolution of the field, techniques have been developed that make it possible to consider a binary program as a malleable entity, something, Vigna says, “You can modify, tear apart, and put back together,” adding, “A lot of research that has come out of UCSB has been focused on this binary manipulation, which has a number of different applications, from protecting binaries to removing parts of a binary that you don’t need or want because they may include vulnerabilities or increase the exposure to code-reuse attack, one in which part of the existing benign code is re-used to perform malicious actions.”

Patching at the binary, machine-code level is extremely difficult, because there, Vigna says, “You don’t have the high-level abstractions that you have in the source code, which allow you to better understand certain properties of the program.”

Instead, he explains, patching the binary code is similar to fixing a house without having a blueprint or plan of the whole house, so that you see only a tiny square, perhaps a door, and can only make it blue or white. “You see a tiny granular piece of it, and from there, you have to reconstruct the high-level vision of everything that’s going on and then make sure that the behavior is the same,” Vigna says. “You’re down in the zero-one sequence, trying to figure out where the patch needs to go. This adds an enormous amount of complexity but also makes the approach applicable to everything, because everything is binary. Your heater, your microwave oven — they are all controlled by microprocessors running binary code.”

Naturally, computer scientists want to avoid having to recompile an entire system to fix a single vulnerability. Says Vigna,” I just want to be able to make this change to this binary that will fix a probable vulnerability and not have to think about it anymore. And I want some formal assurance that I didn’t make a mistake and introduce some new vulnerabilities, or create an unstable program. A lot of work goes into being able to demonstrate to you that my modification has fixed the problem without changing the behavior of the program.

Another key to a desirable patching system is that once the patch is made, the system does not have to be retested. “If I can prove to you that the vulnerability is fixed but that the system will otherwise operate in exactly the same way as it always did, then you don’t have to test it again,” Vigna notes. “That saves time, improves security, and employs the system that makes binary code malleable.”

Vigna, working with fellow UCSB computer science professor Christopher Kruegel and new graduate Aravind Machiry (PhD 2020), soon to start as a professor at Purdue, has developed new technology to verify security patches, but the proposed technique applies only to source code. The new DARPA project is focused on extending the approach to binary code to improve its effectiveness and expand its applicability to the software running on the millions of devices that surround us every day.


Illustration of a person at a keyboard working working with binary code to provide a patch for software in an airliner.