Shimware: Toward Practical Security Retrofitting for Monolithic Firmware Images

In today’s era of the Internet of Things, we are surrounded by security- and safety-critical, network-connected devices. In parallel with the rise in attacks on such devices, we have also seen an increase in devices that are abandoned, reached the end of their support periods, or will not otherwise receive future security updates. While this issue exists for a wide array of devices, those that use monolithic firmware, where the code and data are opaquely intermixed, have traditionally been difficult to examine and protect. In this paper, we explore the challenges of retrofitting monolithic firmware images with new security measures. First, we outline the steps any analyst must take to retrofit firmware, and show that previous work is missing crucial aspects of the process, which are required for a practical solution. We then automate three of these aspects-locating attacker-controlled input, a safe retrofit injection location, and self-checks preventing modifications-through the use of novel automated program analysis techniques. We assemble these analyses into a system, Shimware, that can simplify and facilitate the process of creating a retrofitted firmware image, once the vulnerability is identified. To evaluate Shimware, we employ both a synthetic evaluation and actual retrofitting of three case study devices: a networked bench power supply, a Bluetooth-enabled cardiac implant monitor, and a high-end programmable logic controller (PLC). Not only could our system identify the correct sources of input, injection locations, and self-checks, but it injected payloads to correct serious safety and security-critical vulnerabilities in these devices.</p

Static Binary Rewriting for ROP Gadget Removal

Return-Oriented Programming (ROP) is an exploitation technique that is commonly used by malicious users. It works by leveraging return statements in binaries to gain control over the execution of programs. Some mitigations for ROP include changing the binary during compilation time, rewriting the binary after compilation, and adding runtime checks to the binary. The focus of this study was rewriting the binary after compilation. Rewriting during compilation time requires end users to have access to source code, which, in most cases, they will not. Adding runtime checks adds additional overhead to the target binary. The areas this study aimed to improve in the binary rewriting space were twofold. The first was improving static binary rewriting. This was done by attempting to see if the amount of information needed to correctly rewrite a binary could be reduced compared to other tools. The second area was attempting to use static binary rewriting to reduce the number of potential ROP gadgets in a binary. The ROP gadgets that were targeted were those created by splitting an instruction that contains a return in them to create new ROP gadgets. This was chosen because most current tools focused on the safety of standard returns from function ends. To determine if static binary rewriting could be used to reduce the amount of ROP gadgets created from mid-instruction ROP gadgets, a design science approach was taken. There were two artifacts that were created through two design cycles. The first artifact aimed to create a static binary rewriter that collected minimal amount of information from binaries. The second artifact built upon the first artifact and attempted to use it to remove instructions that contained a mid-instruction return. After the removal of the mid-instruction return, the second artifact inserted instructions that allowed for the same functionality of the binary, but without the return byte