Co-processor-based Behavior Monitoring Application to the Detection - PowerPoint PPT Presentation

Co-processor-based Behavior Monitoring Application to the Detection of Attacks Against the System Management Mode ACSAC, December 7, 2017 Ronny Chevalier 1,2 Maugan Villatel 1 David Plaquin 1 Guillaume Hiet 2 1 HP Labs, United Kingdom ( firstname.lastname@hp.com ) 2 Team CIDRE, CentraleSupélec/Inria/CNRS/IRISA, France ( firstname.lastname@centralesupelec.fr )

Introduction SMM Behavior Monitoring Approach overview How to define a correct behavior? How to monitor? Evaluation Related Work Conclusion

Computers rely on firmware UEFI Less More Privileges Applications System Operating Firmware Hardware Where can we find firmware? • Stored in a flash • Highly privileged runtime software • Early execution • Tightly linked to hardware • Low-level software What is it? Here, we focus on BIOS/UEFI-compliant firmware Mother boards (e.g., BIOS), hard disks, network cards,... 1

What is the problem? BIOS is often written in unsafe languages (i.e., C & assembly) Memory safety errors (e.g., use after free or buffer overflow) BIOS is not exempt from vulnerabilities [Kallenberg et al. 2013; Bazhaniuk et al. 2015] Why compromise BIOS? • Malware can be hard to detect (stealth) • Malware can be persistent (survives even if the HDD/SSD is changed) and costly to remove What do we want? • Boot time integrity • Runtime integrity 2

What are the currently used solutions? Operating our focus is with the System Management Mode (SMM) Isolation of critical services available while the OS is running Runtime Report Measure & Verify Updates Signed System Bootloader Boot time Firmware UEFI Root of Trust Immutable • Immutable hardware root of trust Module (TPM) chip • Measurements and reporting to a Trusted Platform • Signature verification before executing • Signed updates 3

What are the currently used solutions? Operating Isolation of critical services available while the OS is running Runtime Report Measure & Verify Updates Signed System Bootloader Boot time Firmware UEFI Root of Trust Immutable • Immutable hardware root of trust Module (TPM) chip • Measurements and reporting to a Trusted Platform • Signature verification before executing • Signed updates 3 → our focus is with the System Management Mode (SMM)

Introducing the System Management Mode (SMM) Highly privileged execution mode for x86 processors Runtime services BIOS update, power management, UEFI variables handling, etc. How to enter the SMM? • Trigger a System Management Interrupt (SMI) • SMIs code & data are stored in a protected memory region: System Management RAM (SMRAM) BIOS code is not exempt from vulnerabilities affecting SMM [Bazhaniuk et al. 2015; Bulygin, Bazhaniuk, et al. 2017; Pujos 2016] Why is it interesting for an attacker? • Only mode that can write to the flash containing the BIOS • Arbitrary code execution in SMM gives full control of the platform 4

Our objective Response • How to monitor? • How to define a correct behavior? • How to ensure the integrity of the monitor? Such goal raises the following questions: Monitoring Behavior ... Stop execution or Raise alert or Firmware Runtime Monitor behavior at runtime . 5 Our goal is to detect attacks that modify the expected behavior of the SMM by monitoring its

Introduction SMM Behavior Monitoring Approach overview How to define a correct behavior? How to monitor? Evaluation Related Work Conclusion

Approach overview integrity of the monitor? How to define a correct behavior? BIOS source code code SMM source Compilation bridging the semantic gap How to monitor? Semantic gap? How to ensure the Co-processor RAM SMM code target behavior Expected Processor Co-processor Monitor Target Processor RAM 6

Approach overview integrity of the monitor? How to define a correct behavior? BIOS source code code SMM source Compilation bridging the semantic gap How to monitor? Semantic gap? How to ensure the Co-processor RAM SMM code target behavior Expected Processor Co-processor Monitor Target Processor RAM 6

Approach overview integrity of the monitor? How to define a correct behavior? BIOS source code code SMM source Compilation bridging the semantic gap How to monitor? Semantic gap? How to ensure the Co-processor RAM SMM code target behavior Expected Processor Co-processor Monitor Target Processor RAM 6

Approach overview Semantic gap? channel Communication How to define a correct behavior? BIOS source code code SMM source Compilation bridging the semantic gap How to monitor? integrity of the monitor? Co-processor RAM How to ensure the SMM code Instrumented target behavior Expected Processor Co-processor Monitor Target Processor RAM 6

Approach overview Semantic gap? channel Communication How to define a correct behavior? BIOS source code code SMM source Compilation bridging the semantic gap How to monitor? integrity of the monitor? Co-processor RAM How to ensure the SMM code Instrumented target behavior Expected Processor Co-processor Monitor Target Processor RAM 6

Introduction SMM Behavior Monitoring Approach overview How to define a correct behavior? How to monitor? Evaluation Related Work Conclusion

How to define a correct behavior? Our use case: SMM code • Written in unsafe languages (i.e., C & assembly) • Tightly coupled to hardware Control Flow Graph (CFG) Define the control flow that the software is expected to follow Invariants on CPU registers Define rules that registers are expected to satisfy 7 → Such languages are often targeted by attacks hijacking the control flow → Such software modifies hardware configuration registers → Control Flow Integrity (CFI) → CPU registers integrity

How to define a correct behavior? Control Flow Integrity (CFI): principle Authenticated authenticated Non verification auth Simplified graph 8 Example void auth( int a, int b) { char buffer[512]; [...vuln...] verification(buffer); } void verification( char *input) { if (strcmp(input, "secret") == 0) authenticated(); else non_authenticated(); }

How to define a correct behavior? Control Flow Integrity (CFI): principle Authenticated authenticated Non verification auth Simplified graph 8 Example void auth( int a, int b) { char buffer[512]; [...vuln...] verification(buffer); } void verification( char *input) { if (strcmp(input, "secret") == 0) authenticated(); else non_authenticated(); }

How to define a correct behavior? Control Flow Integrity (CFI): principle Goal: constrain the execution path to follow a control-flow graph (CFG) Authenticated authenticated Non verification auth Simplified graph 8 Example void auth( int a, int b) { char buffer[512]; [...vuln...] verification(buffer); } void verification( char *input) { if (strcmp(input, "secret") == 0) authenticated(); else non_authenticated(); }

How to define a correct behavior? Control Flow Integrity (CFI): type-based verification We focus on indirect branches integrity Type-based verification Ensures the integrity of indirect calls 9 typedef struct SomeStruct { [...] char (*foo)( int ); } SomeStruct; int bar(SomeStruct *s) { char c; [...] c = s->foo(31); [...] }

How to define a correct behavior? Control Flow Integrity (CFI): type-based verification We focus on indirect branches integrity Type-based verification Ensures the integrity of indirect calls 9 typedef struct SomeStruct { [...] char (*foo)( int ); } SomeStruct; int bar(SomeStruct *s) { char c; [...] c = s->foo(31); [...] }

How to define a correct behavior? Control Flow Integrity (CFI): type-based verification We focus on indirect branches integrity Type-based verification Ensures the integrity of indirect calls 9 typedef struct SomeStruct { [...] char (*foo)(int); } SomeStruct; int bar(SomeStruct *s) { char c; [...] c = s->foo(31); [...] }

How to define a correct behavior? i32(i8) Message Call Site ID 1561 Target Address Message Call Site ID Type 1561 i8(i32) 4852 ... Instrumented ... Function Address Type i8(i32) i32() ... ... Compilation SMM source code valid? Control Flow Integrity (CFI): type-based verification SMM code Message Monitor We focus on indirect branches integrity Type-based verification Ensures the integrity of indirect calls Target Runtime Compile time 9 Runtime Target Address Message 1561 Call Site ID Compile time 0x0fffb804 typedef struct SomeStruct { [...] char (*foo)( int ); } SomeStruct; int bar(SomeStruct *s) { char c; 0x0fffb804 [...] 0x0fffb804 c = s->foo(31); 0x0befca04 [...] }

How to define a correct behavior? i32(i8) Message Call Site ID 1561 Target Address Message Call Site ID Type 1561 i8(i32) 4852 ... Control Flow Integrity (CFI): type-based verification ... Function Address Type i8(i32) i32() ... ... Compilation SMM source code valid? SMM code Instrumented Message Monitor We focus on indirect branches integrity Type-based verification Ensures the integrity of indirect calls Target Runtime Compile time 9 Runtime Compile time Message Target Address 1561 Call Site ID 0x0fffb804 typedef struct SomeStruct { [...] char (*foo)(int); } SomeStruct; int bar(SomeStruct *s) { char c; 0x0fffb804 [...] 0x0fffb804 c = s->foo(31); /* Call Site ID = 1561 */ 0x0befca04 [...] }