N152-120     TITLE:  Attack Sensitive Brittle Software

TECHNOLOGY AREAS:  Information Systems

ACQUISITION PROGRAM:  PEO-SHIPS, PEO-C4I, PMW-130

OBJECTIVE:  Develop transformation mechanisms that can be applied to software to achieve “fast-crash” property where successful attacks/compromises will cause the software to cease operating rather than continuing to operate in an unsafe state.

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 “fastcrash” 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.

REFERENCES:  

1.                B. Cox, et.al, “N-Variant Systems: A Secretless Framework for Security through Diversity”, USENIX Security Symposium, Vancouver, BC, 3 August 2006.

2.                M. Castro, B. Liskov, "Practical Byzantine Fault Tolerance and Proactive Recovery". ACM Transactions on Computer Systems (Association for Computing Machinery) 20 (4): 398–461.

3.                . L. Q. Nguyen, T. Demir, J. Rowe, F. Hsu, K. N. Levitt, “A framework for diversifying windows native APIs to tolerate code injection attacks,” In Proceedings ACM Symposium on Information, Computer and Communications Security (ASIACCS), pp. 392-394, March 2007.

4.                Martín Abadi and Gordon D. Plotkin. 2012. On Protection by Layout Randomization. ACM Trans. Inf. Syst. Secur. 15, 2, Article 8 (July 2012).

5.                Richard Wartell, Vishwath Mohan, Kevin W. Hamlen, and Zhiqiang Lin. 2012. Binary stirring: selfrandomizing instruction addresses of legacy x86 binary code. In Proceedings of the 2012 ACM conference on Computer and communications security (CCS '12). ACM, New York, NY, USA, 157-168.

KEYWORDS:  Cyber physical systems, Cyber security, Resiliency, Fault tolerant, Control Systems, Critical control system

** TOPIC AUTHOR (TPOC) **

DoD Notice:   Between April 24 and May 25, 2015 you may talk directly with the Topic Authors (TPOC) to ask technical questions about the topics. Their contact information is listed above. For reasons of competitive fairness, direct communication between proposers and topic authors is not allowed starting May 26, 2015 , when DoD begins accepting proposals for this solicitation.

However, proposers may still submit written questions about solicitation topics through the DoD's SBIR/STTR Interactive Topic Information System (SITIS), in which the questioner and respondent remain anonymous and all questions and answers are posted electronically for general viewing until the solicitation closes. All proposers are advised to monitor SITIS (15.2 Q&A) during the solicitation period for questions and answers, and other significant information, relevant to the SBIR 15.2 topic under which they are proposing.

If you have general questions about DoD SBIR program, please contact the DoD SBIR Help Desk at 800-348-0787 or sbirhelp@bytecubed.com.