N00014-17-S-B010_Amendment_0003_Attachment_1_(Industry_Day_Technical_Slides).pdf

ONR BAA Industry Day Late-stage Software Customization and Complexity

Reduction S&T for Legacy Naval Systems (N00014-17-S-B010)

DISTRIBUTION A. Approved for public release: distribution unlimited.

UNCLASSIFIED

28 March 2017

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 2 of 21

Introduction

• ONR office: Code 311 – Computer, Mathematics & Information Sciences Division)

• ONR Cyber Program Officers involved:

– Mr. Gary Toth

– Dr. Sukarno Mertoguno,

– Dr. Ryan Craven

– Dr. Daniel Koller

– Mr. Ryan Gunst (clifford.gunst@navy.mil)

• All technical questions should be directed to Mr. Gunst

• All proposals should be addressed to Mr. Toth (1 May)

– Detailed instructions in the BAA mailto:clifford.gunst@navy.mil

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 3 of 21

BAA Overview (N00014-17-S-B010)

• Title: Late-stage Software Customization and Complexity Reduction S&T for Legacy Naval Systems

• Five Technical Areas (TA):

1. Functionality identification and reduction

2. De-bloat/de-layer (functionality-preserving complexity reduction)

3. Addition of security constructs

4. Verification and Validation

5. Supportive and complementary approaches

FY17 FY18

* Approximate

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 4 of 21

Tech Push

• Important: This is not a purely basic research BAA

• Goal of this effort is to aggressively push novel and game-changing technology to the fleet

• In your proposals, consider how you will create tools that can be transitioned to and used by a government lab

• Univ.: this may require you to consider including engineering support Target customer

Types of S&T programs within ONR:

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 5 of 21

BACKGROUND: Modern software is exceedingly complex and bloated

- Current practices encourage it (OOP, layers of abstraction, etc.)

- Priority is to maximize code reuse and increase programmer productivity

- One-size-fits-all feature set

SW Complexity and Bloat

Rube Goldberg machine

Complicated gadget that performs simple tasks in indirect, convoluted ways

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 6 of 21

BACKGROUND: Modern software is exceedingly complex and bloated

- Current practices encourage it (OOP, layers of abstraction, etc.)

- Priority is to maximize code reuse and increase programmer productivity

- One-size-fits-all feature set

SW Complexity and Bloat

“In every application we looked at, an enormous amount of activity was executed to accomplish simple tasks.”

“For example, a stock brokerage benchmark executes 268 method calls and creates 70 new objects just to move a single date field from SOAP to Java.”

Excerpted from:

Sevitsky et. al. (IBM TJ Watson Research Center) on framework based applications http://lcsd05.cs.tamu.edu/papers/sevitsky_et_al.pdf

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 7 of 21

SW Complexity and Bloat

EXISTING APPROACHES:

REACTIVE

• Patching

• Signature-based malware scanning

EXPENSIVE & OFTEN

IMPERFECT DEFEATABLE TRICKS

• Address Space Layout Randomization (ASLR)

• Stack canaries

• Anti-ROP (ret frequency counting, etc.)

• API guards

• Shadow stacks

• Control-flow Integrity

EXACERBATES SECURITY ISSUES:

• Widespread use of untrusted 3rd party libraries and runtime environments (broad attack surface)

• Security analysis is more difficult (more code, more complexity)

• One size fits all approach enables more robust attack planning and makes code reuse attacks easier

WEB BROWSER

RUNTIME

LIBRARIES (…)

Webkit

JavaScript Engine XML

CSS

Parser

LIBRARIES (…)

libXML

Openssl Etc… libpng

Layers, wrappers

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 8 of 21

Underlying analysis (code analysis, control-flow extraction, etc.)

RESEARCH VISION: Late-stage / install-time transformations

– Hard to change the way people write code, so work around it

– Series of automated transformations for legacy code

– Four independent, separate steps

• Trimming tools should cut as aggressively as possible

• Underlying analysis needed by each tool is different, but will likely overlap

Improving Software Robustness and Efficiency Architecture & Strategy for Development & Deployment

Feature Removal de-Layer de-Bloat

Harden Security

Verify and Validate

Executable code

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 9 of 21

Underlying analysis (code analysis, control-flow extraction, etc.)

RESEARCH VISION: Late-stage / install-time transformations

– Hard to change the way people write code, so work around it

– Series of automated transformations for legacy code

– Four independent, separate steps

• Trimming tools should cut as aggressively as possible

• Underlying analysis needed by each tool is different, but will likely overlap

Improving Software Robustness and Efficiency Architecture & Strategy for Development & Deployment

Feature Removal de-Layer de-Bloat

Harden Security

Verify and Validate

Executable code

TA1 TA2 TA3 TA4

TA5

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 10 of 21

TA1: Functionality Identification and Reduction

• Functionality non-preserving; preserving with respect to the reduced set

• Someone needs to specify (admin?)

• Selecting desired features

• Feature removal

– RE&A

– Feature-code association

– Communicating desired features

• Feature removal in dynamic languages

– Specifying special order for dynamic language feature removal

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 11 of 21

TA2: De-bloat/de-layer

• Functionality-preserving

• Compiled and dynamic languages

• Reverse engineering & analysis (RE&A) of:

– Binary

– Bitcode, Bytecode, IR

– Scripts

– Undecidable ↔ workaround w/ additional info

• de-Bloating / de-Layering

• Soundness and completeness

– Dynamic can help, but what is practical?

– Test-assisted? Need practical strategy for test deployment and execution…

– Completeness is best effort

• What is the best strategy when a cut feature / function / etc. is invoked?

– For feature removal → Throw error

– For dLB → ??? Maybe error, or dynamically re-enable? Think about this.

– Attacker invoked ← DO NOT WANT!!!

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 12 of 21

TA3: Addition of Security Constructs

• It is unlikely, but security constructs may be trimmed out by earlier steps

• Security analysis & retrofitting

• RE&A

• Analysis with respect to common vulnerabilities and known exploits

• Beyond known stuffs: properties to assure

– type-safety

– others

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 13 of 21

TA4: Verification and Validation

• Functionality-preserving with respect to either full or reduced set of features

• Validation of functionality

• Verification of desired properties

• Formal assertions of (security) properties

– Formal model of execution environment

– Extracted formal model of the program/application

– Formal specification of properties to assure

Extracted

Built once

Built once

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 14 of 21

Assured Transformation

Hardened Transformation

Reduced Attack Surface

• Feature Removal

– Cut unneeded functionality (admin-assist)

– Is a functionality-preserving transformation but only for desired features

• Complexity Reduction (dLB)

– Functionality-preserving transformation for the aggressive reduction of code size/complexity, indirection, and layers of abstraction

• Retrofitting Security

– Security-focused code analysis and functionality-preserving transformations for enhancing robustness and security

• Asserting correctness and security

– Automated and in situ verification of validation to ensure the transformation results are robust and secure

TA1-TA4 Recap

Feature Removal de-Layer de-Bloat

Harden Security

Verify and Validate

Simplified code base

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 15 of 21

TA5: Supportive and complementary approaches

• Intended to catch research complementary to TA1-4

• Enabling or cross-cutting work that will improve the accuracy or robustness of TA1-4 approaches

– Robust executable or binary reverse engineering tools

– Robust binary -> intermediate representation (IR) transforms

– Methods to improve robust IR extraction

– Automated fundamental software transformations that improve the quality & simplicity of software or reduce attack surface of systems and software

• REMEMBER OUR FOCUS ON LEGACY

• Nothing that requires being in a VM, no IDS stuff

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 16 of 21

Advice

We recommend proposals consider the following:

• Must work without developer cooperation (legacy!)

– May not have source code available

• Be very cognizant of your approach's limitations

– Binary transformation is unsolved & very difficult

– Over-confidence without supportive evidence will not instill confidence in your approach amongst the reviewers

– Some limitations are fundamental (e.g., undecidability), but that’s OK—we can still make lots of progress for practical applications

– Just need to be aware of our limits and clearly define them

• The less system properties you rely on, the better

– Approaches that require VM introspection, etc. are discouraged

– Static transformations are preferred

• Automation, automation, automation!

– Semi-automated tools that aid a human are OK (e.g., an admin doing feature cutting)

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 17 of 21

Advice (cont.)

We recommend proposals consider the following:

• Define your scope well:

– Compiled or interpreted languages? Or both?

– Which layer? Web, Apps, OS, Hypervisor, BIOS/firmware?

– None has the advantage over the other, just be upfront. Lots of stuff is used throughout the Navy

• Think about how to avoid clashing with current development methodologies (adds constraints for you, but reduces deployment burden in the end)

• This is cool stuff! Have fun :)

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 18 of 21

Programmatics

• Award lengths:

– Requesting 1-3 year base + options (total NTE 5 years)

– Anticipated start dates:

• Grants: Nov 1, 2017

• Contracts: Jan 1, 2018

• Funding levels: Up to ~$1.5M/yr (smaller efforts are OK)

• IMPORTANT: Recall tech push slide…need to deliver tools

– Options can be for maturing tools, transition work w/ Navy, etc.

– Later years may involve some collaborative and integrated research with naval environment for deliverables

– Expect to (at minimum annually) spiral code out to our ‘tool curator’

– Tool curator will help us with maturation, QA, documentation & training, etc.

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 19 of 21

Further Reading

Goals of the workshop:

• Explore issues in software/feature reduction

• Study software development & deployment strategies for enhancing efficiencies

• Discuss how to retrofit security in compiled legacy code when source code is and is not available

• Explore current state-of-the-art techniques for supporting late stage software customization (e.g., binary analysis, reassemblers, etc.)

Oct 2016 Workshop:

A public, open audience workshop was hosted by the ACM 2016 International Conference on

Communications and Computer Security (ACM CCS 2016) Workshop was titled FEAST: Forming an Ecosystem Around Software Transformation ONR POs were involved in guiding the focus of the workshop, which examined various issues and limitations surrounding software customization We recommend taking a look at the slides for the keynote which helped frame discussion Plug: FEAST will likely continue at CCS 2017 in Dallas, TX https://sites.google.com/site/ccsfeast16/ ---- or, just google for “ONR FEAST” https://sites.google.com/site/ccsfeast16/ https://sites.google.com/site/ccsfeast16/

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 20 of 21

BACKUP SLIDES

DISTRIBUTION A. Approved for public release: distribution unlimited. Slide 21 of 21

STRATEGY: Recall that transformations are at install-time

– SW developers keep same workflow

– Vanilla copy is kept (potentially on system) when system owner first applies automated tools

– Patches are applied to vanilla copy; tools must be rerun

FAQ: How would I apply patches?

Vendor-supplied code

Transformed code / shadow libraries

Vendor patch

Execute:

Maintain (potentially on system):

Furthers need for the tools to be automated