TrackOS: a Security-Aware RTOS 3 Presentations/1020-1… · An RTOS Foundation 1.Insight: need a runtime monitoring approach: formal verification can be too difficult and may not

© 2012 Galois, Inc. All rights reserved.© 2012 Galois, Inc. All rights reserved. PA approval number: *88 ABW/PA 2012-2905

TrackOS: a Security-Aware RTOS

Lee Pike ([email protected]), Galois Inc. | AFRL S5 | June 2012with

Pat Hickey, Trevor Elliott, Aaron Tomb, Eric Mertens (Galois Inc.)David Kapp and Daniel Koranek (AFRL)

© 2012 Galois, Inc. All rights reserved.

Problem Space:Embedded System Security

Siemens Simatic S7-300.src: http://en.wikipedia.org/wiki/File:S7300.JPG

Stuxnet

src: The New York Times

src: http://www.securitymanagement.com/news/trouble-with-uavs-008118

src: http://en.wikipedia.org/wiki/File:FIRESCOUT-VUAS.jpg


Problem Space:The Present and Future

● Multiple radios access points and sensors systems

● 10s-100s of heterogeneous microcontrollers

● Highly-networked

● Mixed criticality

● Millions of lines of code

src: http://en.wikipedia.org/wiki/File:HURT_concept_drawing.jpg

DARPA's Heterogeneous Urban RSTA Team (HURT) program

http://en.wikipedia.org/wiki/File:HURT_concept_drawing.jpg


How to Hack Embedded Software

● Let's focus on software integrity

● The same attacks from the 80s still work!● Just have to be ported to the embedded world

● Main approaches:

– Shellcode: inject a new program

– Return-to-libc: build a new program from spare parts

– Reflashing: overwrite data (including the original program)● For control-intensive programs, you can also change timing

– Used in Stuxnet to destroy centrifuges!


Current Approaches to Security

Typical security approaches make attacks harder...

● Address-space layout randomization

● Write XOR Execute (W^X)

● Stack canaries


Current Approaches to Security

Typical security approaches make attacks harder...

● Address-space layout randomization

● Write XOR Execute (W^X)

● Stack canaries

But not impossible:

Nobody ever defended anything successfully, there is only attack and attack and attack some more.

– General George S. Patton


Outline

1. Our approach: unbypassable detection

2. Requirements for real-time embedded systems

3. Implementation challenges and solutions

4. Prototype and case-studies

5. Next Steps


From Roadblocks to Unbypassable Detection

Control-flow Integrity (CFI): does a program respect its statically-computed call-graph?




executable

sourcefile 0

src: http://en.wikipedia.org/wiki/File:PIC18F8720.jpg

call-graph

sourcefile 1

sourcefile n

. . .

execution trace

compile

executionsymbolically generate




src: http://en.wikipedia.org/wiki/File:PIC18F8720.jpg

call-graphexecution trace

execution

trace?function

returnaddress

executable

sourcefile 0

sourcefile 1

sourcefile n

. . .

compile

symbolically generate


Embedded Security Monitoring:Just the FaCTS

Requirements for an embedded systems security monitor:

● False-positives are kept minimal

● Compositional: scalable over networked systems

● Timing constraints are respected

● Source code isn't modified (and not needed)

Can we have our cake (unbypassable CFI) and eat it (satisfy the FaCTS) too?


An RTOS Foundation

1. Insight: need a runtime monitoring approach: formal verification can be too difficult and may not have access to code


An RTOS Foundation


2. Insight: real-time operating systems (RTOS) are small (can be 5KB binaries) and provide scheduling primitives


An RTOS Foundation



3. Insight: RTOSes are fairly trustworthy: created by computer science experts with wide user-bases


An RTOS Foundation



3. Insight: RTOSes are fairly trustworthy: created by computer science experts with wide user-bases

4. Insight: application code is not trustworthy● Often large code-base used in a single application

● May be written by domain-expert (i.e., control engineer), not a software expert

● Application code is what touches the real-world (e.g., radios and sensors)


Real-Time Operating System (RTOS)

TrackOSTask

UntrustedTask 0

control stack

return address

data

UntrustedTask n

. . .

OS-providedaccess


Real-Time Operating System (RTOS)

TrackOSTask

UntrustedTask 0

control stack

return address

data

non-volatile memory

UntrustedTask n

. . .

constructed trace

OS-providedaccess


TrackOS: Implementation Challenges (1/2)

Data bytes vs. return addresses

● Problem: on microcontrollers, we cannot assume frame pointers.

● Solution: static analysis tells us the number of data bytes to skip.

control stack

3

2}

}


TrackOS: Implementation Challenges (2/2)

Call-graph vs. control-stack ordering

● Problem: easiest to traverse the control-stack from the bottom, but we must traverse the entire stack to see the current program location

● Solution: Check from the top● Heuristics to find the initial return address

● Real-time stack checking at approx. 0.5 milliseconds on a 16MHz processor in our testing

main

foofoo

bar

mostrecent


Beyond CFI: TrackOS Extensions

● Timing integrity: did the task perform in the expected time?

● Example: is GPS data parsed in the expected time?

● Blacklisting: check the control stack for functions in the call-graph that become invalid.

● Example: calling startup code after initialization completes.

● Data integrity: data-integrity checks ensuring memory isn't modified.

● “Trusted Platform Modules for embedded code.” Off-chip checks that memory has not been modified. See SWATT: Arvind Seshadri et al. SoftWare-based ATTestation for embedded devices. In IEEE Symposium on Security and Privacy, May 2004.

200ms

challenge

response


Implementation

TrackOS is a technology/approach that is RTOS and hardware agnostic

● Our prototype uses open-source software and common hardware: FreeRTOS on an Atmel AVR microprocessor

● A custom simple hardware simulator for symbolic analysis

● Case-study: the open-source ArduPilot autopilot● Altitude hold, stabilization, collision avoidance, waypoint tracking, GPS

hold...

● Over 100k LOCs, used by NASA, universities, etc.


src: http://code.google.com/p/ardupilot/

http://code.google.com/p/ardupilot/


Shortcomings & Research Challenges

● Attack discovery is only as good as your statically-computed call-graph.

● For difficult-to-compute aspects (e.g., indirect calls, data-dependent loops), we provide configuration data. The analyzer will tell you when it failed.

● Attack analysis is at the rate you schedule it.● Our mitigation: quick checks for the top of the stack; full stack checks

during slack in the schedule.

● Security depends on the RTOS being memory-safe.● Formally-verified RTOSes?


Summary

● TrackOS is real-time and returns no false-positives (assuming conservative static analysis)

● TrackOS provides unbypassable detection of malicious control-flow modifications (assuming sufficient frequency)

● TrackOS scales to large programs

● TrackOS requires no access to the source code of the analyzed program and is compiler-independent


Next Steps

● Galois Inc. is actively completing TrackOS under AFRL SBIR Phase III funding

● Currently looking for technology transition partners—to programs or new products

[email protected]


Appendix


Further Reading on CFI

● Martin Abadi, Mihai Budiu, Ulfar Erlingsson, and Jay Ligatti. Control-flow integrity: principles, implementations, and applications. ACM Transactions on Information and System Security, 2009.

● Iavor Diatchki, Lee Pike, and Levent Erkok. Practical considerations in control-flow integrity monitoring. 2nd Intl. Workshop on Security Testing (SECTEST), 2011.

Documents

TrackOS: a Security-Aware RTOS 3 Presentations/1020-1… · An RTOS Foundation 1.Insight: need a runtime monitoring approach: formal verification can be too difficult and may not