Security Vulnerabilities due to Memory Errors

1. Security Vulnerabilities due to Memory Errors James Newell CS 598yyz Sept. 22, 2005

2. Motivation • Analyze how spurious bit-flips in memory can compromise system security • An Experimental Study of Security Vulnerabilities Caused by Errors • Using Memory Errors to Attack a Virtual Machine

3. An Experimental Study of Security Vulnerabilities Caused by Errors By J. Xu et al. CRHC Lab at University of Illinois Urbana-Champaign In Proc. of DSN 2001

4. Outline • Overview of target applications and their authorization mechanism • ftpd • sshd • Experimental analysis using fault-injection • Experiment description • Result categorization • Results analysis • New instruction set encoding scheme proposal

5. File Transport Protocol (FTP) • Overview • Internet protocol used to transfer files • Client-server based • wu-ftpd-2.6.0 • Authentication mechanism • user() and pass() functions authorize and authenticate • 5.8% of source-code • 8% of binary • Branch instruction account 13% of code

6. if ( … && (strcmp(xpasswd, pw->pw_passwd == 0)) { rval = 0; } if ( rval ) { /* deny access */ … /* grant access */ … <216> push %eax # pw->pw_passwd <217> push %ecx # xpasswd <218> call <strcmp> # call strcmp() <223> add $0x8,%esp # shrink stack <226> test %eax,%eax # test if return # value is 0 <228> jne <232> # not 0, to <232> <230> xor %ebx,%ebx # if 0, rval = 0 <232> test %ebx,%ebx # is rval 0? <234> je <1203> # 0, grant <240> push $0x8062907 # not 0, deny ... deny access and return ... <1203> ... grant access ... %jne = 0x75 %je = 0x74 %jne = 0x75 %je = 0x74 FTP Pass() Analysis %eax = 0x50 %ecx = 0x51 <216> push %ecx # xpasswd <228> je <232> # if 0, to <232> C Code Assembly Code • Taken from FTP’s Pass() function • Responsible for validating password

7. Secure Shell (SSH) • Overview • Used to log into *nix host remotely (and securely) • ssh-1.2.30 by SSH Communications Security • Authorization mechanism • do_authentication(), auth_rhosts(), and auth_password() • 3.6% of source-code • 2.1% of binary • Branch instruction account 12% of code

8. SSH Function Analysis • Taken from packet_read() function • Data errors can result in stack overflow • push $0x2000 • Calling stack for read • Control flow error in read int packet_read(void) { char buf[8192]; ... /* read packet from network */ len = read(connection_in, buf, sizeof(buf)); ... } push $0x2000 # sizeof(buf) lea -0x2080(%ebp),%esi # buf push %esi pushl 0x8077604 # connection_in call 804a4a8 <read> # call read C Code Assembly Code

9. Experimental Analysis • Selective-exhaustive fault injection • Only authorization section of text segment • Only one-bit flipped on server per client run • Every bit is flipped • NFTAPE • Load program to memory • Sets breakpoint where to inject fault • Breakpoint is monitored to determine if fault was injected on client-run

10. Experimental Setup • FTP Setup • Inject errors in user() and pass() • Client1: existing username, wrong password • Client2: existing username, right password • Client3: non-existing username and password • Client4: logs in as anonymous user • SSH Setup • Inject errors into do_authentication(), auth_rhosts(), and auth_password() • Client1: existing username, wrong password • Client2: existing username, right password

11. FTP Experimental Results NA: Not Activated NM: Activated, but not Manifested SD: System Crash FSV: Fail Silence Violation BRK: Security Break-in

12. SSH Experimental Results • Observations • SSH’s C code is more compact • SSH has more entry mechanisms • Heavier loads tend to have higher error manifestations

13. Transient Exploitable Window • System doesn’t crash instantly • 91.5% crash < 100 • 8.5% crash 100’s, 1,000’s, or 10,000’s • Does not include kernel instructions • Opportunity for transient security hole • None found during examination Number of Instructions between Error and Crash (log scale)

14. New Encoding Scheme JO’: 0111 0000 JNO’: 0110 0001 JO: 0111 0000 JNO: 0111 0001 • 44.5% to 81% of BRK and FSV was due to conditional opcode changes • x86 (and SPARC) use continuous encoding • Propose new encoding using last bit of most sig. 4 bits as parity for least sig. 4 bits • 2-bit Hamming Distance • Swap conflicting opcodes New x86 Conditional Branch Instruction Encoding Mapping

15. Efficacy of New Encoding • Emulated injection via mapping • Previous experiment is repeated • FTP • 86% reduction in BRK • 21 to 40% reduction in FSV • SSH • 21% reduction in BRK • 34 to 38% reduction in FSV

16. Conclusion and Discussion • Small, but non-negligible chance (~1%) of permanent security vulnerability due to memory-errors • Most vulnerabilities are due to changes in branch instructions (opcode and operand) • Transient windows of vulnerabilities can occur before system crashes (~4%) • New encoding-scheme does a decent job of reducing vulnerabilities Discussion Questions at End

17. Using Memory Errors to Attack a Virtual Machine By S. Govindavajhala and A. Appel Princeton University In Proc. Of Symposium on Security and Privacy, 2003

18. Outline • Attack Program and Exploitation • Qualitative Analysis • Experimental Analysis • Physical Fault Injection • Countermeasures • Discussion

19. Virtual Protection • Non-type safe Languages (C/C++) • Protection via OS and virtual memory • Processes typically use message-passing/RPCs • Virtual Machines (Java, .NET) • Proof-carrying code from just-in-time compiler • Link-time type-checking and byte-code verifier • Untrusted program can run in same address space as trusted parts of VM • Use OO shared-memory interfaces

20. VM Attack • Attack window of vulnerability between link-time type checking and use of code. • Java Applet • Fill heap with specially crafted classes • Circumvent type-checking • Exploit error to overtake VM Byte-code verifier Protected VM Memory Untrusted Attack Applet Memory Error Detected Running Trusted Applet Exploit Memory Error

21. Attack Program Concept A • If 2i > object size, a pointer of type A will not reference an object of type B • If 2i < object size, the pointer will reference somewhere within class A Class B { A a1; A a2; A a3; A a4; A a5; A a6; A a7; } Class A { A a1; A a2; B b; A a4; A a5; int i; A a7; } B 2i i B Cosmic Ray Two classes with sizes of power of 2

22. Attack Program .a6 • Continually check if references to A have changed (via ==) • When change is detected, create a B pointer that really points to type A • Now we have two pointers of type A and type B both pointing at A .b .a6 // reference a6 has changed A randPtr = b200.a6; // bPtr will most likely point at // a class of type A B bPtr = randPtr.b;

23. Exploitation • Use contradiction to exploit VM • Use function to write any value into any address in VM address space • Example: Overwrite fields in System.SecurityManager A aPtr; // both aPtr and bPtr point at A B bPtr; int offset = 6 * 4; // offset of i and a6 void write(int address, int value) { aPtr.i = address – offset; bPtr.a6.i = value; // derefence i in A as a ptr }

24. Exploit Analysis • N = objects in memory • s = words in object • h = words in header • P = bytes of physical memory Exploitable log2 N log2 s 10 2 32 28

25. Experimental Analysis • If errors occur frequently, VM and system crashes are likely • P(exploit before crash) = 71.4% on IBM JVM • Ignoring potentially unsafe bit-flips (2-9) improves P(exploit before crash) = 93.7%

26. Probability of a Memory Error • Natural • Alpha particles: Due to impurities, not likely anymore. • High-energy cosmic-rays: once per several months (and growing) • High-speed buses: unknown • Unnatural • Alpha-particles: can’t penetrate 1mm of plastic • Beta-rays: react with plastic and metal packaging • X-ray: doesn’t work • High-energy protons: not practical • Infrared: works, cheap, but difficult to control error-rate

27. Error-injection Experiment • Setup • Spotlight 2mm from DRAM • Thermometer • Variable AC power supply • Results • 80-100˚ C: predictably expoited VMs • > 100˚ C: OS would crash and boot-disk would be corrupted

28. Memory-Error Attack Countermeasures • Prevent physical access to components • Run machine in favorable environment • ECC memory • Periodically reload memory pages from disk (if possible) • Prevent measures under large number of memory errors • Logging errors

29. Conclusion • VMs are susceptible to being compromised with high-probability from memory-errors • Probability of a successful attack is dependent on: • probability of an error • probability of bit-flip being exploitable • probability of exploiting before system crash • While difficult, it is possible to induce memory-errors using heat

30. Discussion Questions • Should will really worry about this? • Chances of a memory-error are low • Attacks aren’t really practical • Continually probe/attack many systems (ftp/ssh) • Run applet and hijack process memory • Countermeasures can be taken • Are certain types of programs more susceptible to this type of attack? • Other types of hardware-faults that can lead to security vulnerabilities?