You are here

Attack Sensitive Brittle Software

Description:

Critical cyber systems are subject to attacks by the enemy. Generally, resilience and survivability are considered desirable properties for software in these systems. They aim to remain operational, though at a degraded state, when they are compromised. However, this is not always desirable. There may be circumstances where it is preferable for the software to be brittle and simply crash when attacks/exploits are successful. This would be the case when integrity and confidentiality requirements are much more important than availability requirements. Compromised or misbehaving software could be much more dangerous than simple unavailability. Another circumstance is when redundant and diversified backup systems are readily available. A faster failure and timely switch-over would minimize the disruption/damage and actually enhance overall resilience. Brittleness would be a plus in these circumstances. The aim is for the crash to occur as soon as possible after a successful attack and program control is lost. The objective of this solicitation is to develop transformation mechanisms for software that increase brittleness and achieve the “fast-crash” property. The transformation mechanisms should be generic and able to be applied to third party software. They should also preserve the functionality of the original software and incur relatively small computational overheads. We are interested in transformations that act on all layers including binary, byte code, and source code. The “fast-crash” property can be defined as the number of instructions/jumps/stack operations that gets executed after control of the program is lost. Compromised software will eventually crash; our goal is to speed up the crash so that malicious behavior cannot take place before it occurs. As such, “fast-crash” should occur within a handful of instruction/branches. Techniques that enhance resilience and survivability of code segments and systems have been an active area of research. We are looking for techniques that do the opposite. There is currently little research that explicitly aims to create brittleness in software. However, it is often the side-effect of some security techniques especially in the context of artificial diversity and randomization. For example, address space layout randomization (ASLR) aims to prevent buffer overflow attacks by making it difficult to reliably jump to a particular exploited function in memory [4,5]. Attempted attacks would crash the program by attempting jumps to invalid addresses. ASLR would be considered an effective “fast-crash” mechanism. We are looking for other mechanisms of achieving the “fast-crash” property against different categories of attacks such as return oriented programming (ROP). We would consider application, customization, or assessment of existing security mechanisms in the context of “fast-crash”. However, novel mechanisms will be prioritized especially if they are able to be simpler, lighter weight, and more dependable than mechanisms meant for other purposes. It’s important to note that “fast-crash” is different from active integrity verification techniques that directly identify attacks. We are NOT as interested in mechanisms that monitor the system and trigger a crash when attacks are detected. Ideally, the system crash should simply be a byproduct or guaranteed side-effect of a successful attack and compromise. The system should crash quickly and consistently after faults that are associated with deliberate attacks. At the same time, the system should not crash when attacks are not taking place or after random faults. The success of the result will be measured by both the false-positive rate and the false-negative rate. This SBIR topic will also consider active techniques if they are novel, generalized, and easily deployed. Another preference is for techniques that do not require source code and can be applied to raw binaries the military already deploys. PHASE I: Develop and discuss the approach for the “fast-crash” transformation mechanism. Demonstrate the feasibility and effectiveness of the mechanism on arbitrary code segments. Prototypes of components that demonstrate the concept will be desirable. PHASE II: Based upon Phase I effort, develop and demonstrate a fully functioning prototype of the “fast-crash” system on the provided experimental platform. Validate its efficacy during normal system operations and in the face of arbitrary attacks. PHASE III: Upon successful completion of Phase II effort, the performer will provide support in transitioning the technology for Navy use as required. The performer will develop a plan for integrating the product into the Navy’s HM&E software control systems and supervisory systems.

US Flag An Official Website of the United States Government