1. Memory Attacks and Protection through Software Diversity
A little background about myself.
Fall 2014
Presenter: Kun Sun, Ph.D.

2. Outlines What is SoK paper? Two SoK papers Eternal War in Memory
László Szekeres*, Mathias Payer, Tao Wei, Dawn Song, , IEEE Symposium on Security and Privacy, 2013.
Automated Software Diversity
Per Larsen, Andrei Homescu*, Stefan Brunthaler, Michael Franz, IEEE Symposium on Security and Privacy, 2014.
*Thank Laszlo and Andrei for sharing their slides.

3. What is SoK paper?
Systematization of Knowledge (SoK), in IEEE s&p conference, since 2010
Papers provide a high value to our community but may not be accepted because of a lack of novel research contributions.
survey papers that provide useful perspectives on major research areas;
papers that support or challenge long-held beliefs with compelling evidence,
or papers that provide an extensive and realistic evaluation of competing approaches to solving specific problems.

4. SoK paper
The goal is to encourage work that evaluates, systematizes, and contextualizes existing knowledge.
identify areas that have enjoyed much research attention,
point out open areas with unsolved challenges,
and present a prioritization that can guide researchers to make progress on solving important challenges.

5. Part I: Eternal War in Memory
C/C++ is unsafe
Everybody runs C/C++ code
They surely have exploitable vulnerabilities

6. Overview What are the attacks? What are the deployed protections?
What are the not deployed protections?
Why aren’t they deployed?

7. Attack Model First step: Memory Corruption Attack Second step:
Code Corruption Attack
Control Flow Hijacking
Data-only Attack
Information leak

8. Memory Corruption Attack
Memory errors (bugs)
allow the attacker to read and modify the program’s internal state in unintended ways.
C and C++ are inherently memory unsafe.
writing an array beyond its bounds, dereferencing a null-pointer, or reading an uninitialized variable result in undefined behavior
Finding and fixing all the programming bugs is infeasible

9. Memory Corruption
More aggressive behavior: attacker changes internal program state
Most often: memory contents
Values of variables on stack/heap
Code pointers
Attack vectors
Buffer overflows
Use-after-free/double-free
Uninitialized variables
Format strings

10. Classic Stack Smashing Attack

11. Use-after-free Exploits
Heap overflow

12. Corrupting Newer Pointers

13. Attack Model First step: Memory Corruption Attack Second step:
Code Corruption Attack
Control Flow Hijacking
Data-only Attack
Information leak

14. Modifying the code itself

15. Code Integrity Read-only code pages
Challenge: In just-in-time compilation, a small time window when the generated code is on a writable page.

16. Attack Model First step: Memory Corruption Attack Second step:
Code Corruption Attack
Control Flow Hijacking
Data-only Attack
Information leak

17. Control Flow Hijacking
Attacker takes control of program execution
Program executes code under attacker control
Other name: arbitrary code execution

18. Non-executable data
Read-only
code pages
e.g., Stack

19. Non-executable data Read-only code pages Non-exec.
Inserted Shellcode cannot be executed.
Non-exec.
data pages

20. Return-oriented programming
Read-only
code pages
Non-exec.
data pages

21. Return integrity
Read-only
code pages
Non-exec.
data pages

22. Return integrity Read-only code pages Stack canaries Non-exec.
data pages

23. Hijacking Indirect Calls and Jumps
Read-only
code pages
Stack canaries
Non-exec.
data pages 23

24. Address Space Randomization
Read-only
code pages
Stack canaries
Non-exec.
data pages

25. Address Space Randomization
Read-only
code pages
ASLR
Stack canaries
Non-exec.
data pages

26. Attack Model First step: Memory Corruption Attack Second step:
Code Corruption Attack
Control Flow Hijacking
Data-only Attack
Information leak

27. Data-only Attack
The target of the corruption can be any security critical data in memory,
Security critical variables
configuration data
the representation of the user identity
or keys.

28. Program Data Tampering
Interfere with program execution
Examples
Bypassing DRM/copy protection
Videogame cheating
FPE, GW (DoS)
Online game?

29. Data-only attack Read-only code pages ASLR Stack canaries Non-exec.
data pages

30. Attack Model First step: Memory Corruption Attack Second step:
Code Corruption Attack
Control Flow Hijacking
Data-only Attack
Information leak

31. Information Leaks
Steal program information/state in memory, process metadata, registers, and files, etc.
Valuable information by itself, e.g. credit card, password, encryption key.
Facilitating further attacks, e.g., memory addresses to bypass ASLR
Side channel attacks

32. Information leakage Read-only code pages ASLR Stack canaries Non-exec.
data pages

33. Bypassing ASLR with user scripting
Read-only
code pages
Stack canaries
Non-exec.
data pages

34. Overview What are the attacks? What are the deployed protections?
What are the not deployed protections?
Why aren’t they deployed?

35. Protection Techniques
Deterministic Protection
A low level reference monitor (RM) enforce a deterministic safety policy.
By hardware, like W⊕X
By software, adding RM into code
Probabilistic Protection
Built on randomization or encryption
Instruction Set Randomization
Address Space Randomization
Data Space Randomization

36. Deployed Protections Policy Technique Weakness Perf. Comp.
Hijack protection
W⊕X
Page flags
JIT 1x
Good
Return integrity
Stack cookies
Direct overwrite
Address space rand.
ASLR
Info-leak.
1.1x

37. Overview What are the attacks? What are the deployed protections?
What are the not deployed protections?
Why aren’t they deployed?

38. Control-flow Integrity

39. Control-flow integrity
CFI

40. CFI
p = &f
jmp p
q = &g
jmp q
f() { … }
g() {

41. CFI ID
p = &f
jmp p
q = &g
jmp q
f() { … }
g() { ID

42. CFI ID
p = &f
jmp p
q = &g
jmp q
f() { … }
g() {
check ID ID
check ID

43. CFI p = &f jmp p jmp q f() { … } g() { check if (…) q = &f else q = &gID
p = &f
jmp p
jmp q
f() { … }
g() {
check ?
if (…)
q = &f
else
q = &g ID
check ?

44. Over-approximation problemID
p = &f
jmp p
jmp q
f() { … }
g() {
check ID
if (…)
q = &f
else
q = &g ID
check ID

45. Over-approximation problemID
p = &f
jmp p
jmp q
printf() { … }
system() {
check ID
if (…)
q = &f
else
q = &g ID
check ID

46. Modularity problem ID
printf() { … }
system() { ID

47. CFI Policy Technique Weakness Perf. Comp. Hijack protection W⊕R
Page flags
JIT 1x
Good
Return integrity
Stack cookies
Direct overwrite
Address space rand.
ASLR
Info-leak.
1.1x
Control-flow integ.
CFI
Over-approx.
1.4x
Libraries

48. Memory Safety

49. Memory safety
Pointer
metadata
tracking &
checking

50. Data integrity

51. Object metadata tracking & checking
Data integrity
Object metadata tracking & checking
they only approximate the spatial integrity
enforced by the previously covered bounds checkers in order
to minimize the performance overhead. In all cases the
approximation is due to a static pointer analysis carried out
prior to the instrumentation.

52. Data-flow integrity

53. Data-flow integrity
DFI

54. Summary Policy Technique Weakness Perf. Comp. Hijack protection W⊕R
Page flags
JIT 1x
Good
Return integrity
Stack cookies
Direct overwrite
Address space rand.
ASLR
Info-leak.
1.1x
Control-flow integ.
CFI
Over-approx.
1.4x
Libraries
Generic
protection
Memory safety
SB+CETS
None
2-4x
Data integrity
WIT
Over-approx.,…
1.2x
Data space rand.
DSR
1.3x
Data-flow integrity
DFI
2-3x

55. Challenges in Practical Usage
Why most of defense mechanisms are not used in practice?
the performance overhead of the approach outweighs the potential protection,
the approach is not compatible with all currently used features (e.g., in legacy programs),
the approach is not robust and the offered protection is not complete,
or the approach depends on changes in the compiler toolchain or in the source-code while the toolchain is not publicly available.

56. Run-time Performance Performance significantly impacts adoption
Lowest overhead (negligible)
DEP
ASLR
Stack canaries
Diversity/performance trade-off
Pre-distribution: small overhead (1-11%)
Post-distribution: larger overhead (5-265%)

57. Part II: Automated Software Diversity
Security Problem
Attacks rely on offline information of target
Memory layout
Memory contents (including program code)
Deterministic algorithms
In one word: predictability
Huge advantage for attacker
Attack one instance of program => attack them all

58. Probabilistic Protection
Deterministic Protection
A low level reference monitor (RM) enforce a deterministic safety policy.
By hardware, like W⊕X
By software, adding RM into code
Probabilistic Protection
Built on randomization or encryption
Instruction Set Randomization
Address Space Randomization
Data Space Randomization

59. Deterministic vs. Nondeterministic algorithm
Deterministic algorithm, given a particular input, will always produce the same output, always passing through the same sequence of states.
Nondeterministic algorithm, even for the same input, exhibit different behaviors on different runs.
uses external state, e.g., user input, a global variable, a hardware timer value, a random value, or stored disk data.
timing-sensitive operations, e.g., multiple processors writing to the same data at the same time.
hardware errors causing state change in an unexpected way.

60. Software Diversity

61. Threat (Why Diversity?)
Information Leaks
Memory Corruption Attacks
Control Flow Hijacking
Code Injection
Code Reuse
Program Tampering
Reverse Engineering
Combination of the above

62. Reverse Engineering Goal: discover program semantics (algorithms)
Attacker has access to program binary
security-through-obscurity
Most frequent mitigation: obfuscation

63. What Have We Learned? Attacks are increasing in complexity
Work around defenses (incl. diversity)
Multi-tiered attacks

64. Example: JIT Code Reuse
State-of-the-art multi-tier attack
Attacker finds address of valid code
Uses information leak to read all code pages
Scan code pages for reusable code snippets (ROP gadgets)
Redirect control flow to attack payload (memory corruption)
Ultimate goal: control flow hijacking and more
When compiling expressions containing constant values, just-in-time compilers may embed the constants directly in binary code. This gives the attacker a way to inject arbitrary binary code into the program, by using constants that contain an attack payload.
K. Z. Snow, F. Monrose, L. V. Davi, A. Dmitrienko, C. Liebchen, and A.-R. Sadeghi.
Just-in-time code reuse: On the effectiveness of fine- grained address space layout randomization. In Proceedings of the 34th IEEE Symposium on Security and Privacy, S&P ’13, 2013.

65. Example: Blind ROP Novel ROP attack (from S&P 2014)
Blind information leak
Locate gadgets by trial-and-error
Build gadget chain that writes memory to socket
Used to leak entire program binary
Requires no a priori knowledge of program

66. What to Diversify? Program Code Granularity of Transformations
Control Flow Hijacking
Reverse Engineering
Program Tampering
Granularity of Transformations
Instruction-level
Basic block-level
Loop-level
Function-level
Program-level
System-level
Program Data
Information Leaks
Memory Corruption
Program Tampering

67. Diversifying Transformations
Instruction-level
Instruction Substitution
Equivalent Instructions
Instruction Reordering
Register Allocation
Randomization
Garbage Code Insertion
Basic block-level
Basic Block Reordering
Opaque Predicates
Branch Function Insertion
Loop-level

68. Diversifying Transformations
Function-level
Stack Layout Rand.
Function Parameter Rand.
Randomized Inlining/Outlining/Splitting
Control Flow Flattening
Program-level
Function Reordering
Base Address Rand. (ASLR)
Program Encoding Rand.
Data Randomization
Library Entry Point Rand.
System-level

69. When to Diversify? Design Implementation Compilation Linking
Installation
Loading
Execution
Update

70. Pre-distribution Diversification
Disassembly is hard!
Indirect branches (not known until running time)
Data inside code section
Compile-time information makes diversification easier
Garbage Code Insertion
Register Allocation Randomization
Stack Layout Randomization
more...

71. Post-distribution Diversification
Distributed diversification
Lower costs for developers
Introduces latency
Generally faster diversification
More diversity
Between each run
During execution

72. Security Entropy Logical/formal argument Concrete attacks
Measure entropy/# of different versions
Quantitative, not qualitative
ASLR: entropy matters!!!
Logical/formal argument
Concrete attacks
Test a real attack against hardened binary
Attack-specific metrics

73. Moving Forward Hybrid Approaches Error Reporting & Debugging
Automated Security Evaluation
Side-channels / Information Leaks

74. Reference
Per Larsen, Andrei Homescu, Stefan Brunthaler, and Michael Franz SoK: Automated Software Diversity. In Proceedings of the 2014 IEEE Symposium on Security and Privacy (SP '14).
Laszlo Szekeres, Mathias Payer, Tao Wei, and Dawn Song SoK: Eternal War in Memory. In Proceedings of the 2013 IEEE Symposium on Security and Privacy (SP '13).
Pucella, R.; Schneider, F.B., "Independence from obfuscation: a semantic framework for diversity," Computer Security Foundations Workshop, th IEEE , vol., no., pp.12 pp.,241
K. Z. Snow, F. Monrose, L. V. Davi, A. Dmitrienko, C. Liebchen, and A.-R. Sadeghi. Just-in-time code reuse: On the effectiveness of fine- grained address space layout randomization. In Proceedings of the 34th IEEE Symposium on Security and Privacy, S&P ’13, 2013.

75. Questions?