Multiprocessors May Reduce System Dependability Under File-based Race Condition Attacks

1. Presented on DSN-DCCS June 28, 2007 Multiprocessors May Reduce System Dependability Under File-based Race Condition Attacks Jinpeng Wei, Calton Pu Georgia Institute of Technology Atlanta, Georgia, USA

2. System Dependability: Brief History • Traditionally focused on availability and reliability (have redundancy, keep running) • Now security and safety are urgent issues • Widely deployed software systems have bugs • Software systems are under constant attacks. intended behavior != actual behavior

3. Multiprocessors: Boon or Bane? • Definitely they are good • Better performance • Lower power consumption • More secure: Intrusion detection systems • Unless they fall in bad hands... • Attacker can become faster in a race condition attack, thus making the system less secure.

4. It’s Much Easier to Attack TOCTTOU Vulnerabilities on Multiprocessors

5. Agenda • Background about TOCTTOU and the vulnerabilities with vi and gedit • A probabilistic model for TOCTTOU attacks • Probability analysis of exploiting vi • Probability and event analysis of exploiting gedit • Parallelizing the attack program on a multiprocessor • Conclusion

6. Definition and Scope • TOCTTOU– Time of Check To Time of Use, a kind of file-based race condition in Unix-style systems • Check– Establish some precondition (invariant) about a file • Use– Operate on the file assuming that the invariant is still valid

7. Sendmail Example • Run as root • Operate on files owned by normal users /home/abc/mailbox a symbolic link? Yes Check Error handling Establishing the invariant: /home/abc/mailbox is NOT a symbolic link No Append the new message to /home/abc/mailbox Use Assuming the invariant still holds

8. Sendmail Vulnerability: An Example Sendmail (root) Attacker (abc) Time /home/abc/mailbox a symbolic link? Check Delete /home/abc/mailbox Create symbolic link mailbox, pointing to /etc/passwd No Append the new message to /home/abc/mailbox (actually to /etc/passwd) Use Effect: The attacker may get unauthorized root access!

9. TOCTTOU Vulnerabilities in Red Hat Linux 9 [1] Tested: ~130 utilities from /bin, /sbin and /usr/bin [1] Jinpeng Wei, Calton Pu. FAST’05

10. vi 6.1 Vulnerability • The vulnerability happens when • vi is run by root • vi is editing a file owned by a normal user (also the attacker) • vi saves the file being edited • TOCTTOU pair: <open, chown> • open creates a new file for writing • chown changes the owner of the new file to the normal user. while ((fd = mch_open((char *)wfname, …) …… chown((char*)wfname, st_old.st_uid, st_old.st_gid);

11. gedit 2.8.3 Vulnerability • Similar to the vi vulnerability • gedit is run by root • gedit is editing a file owned by a normal user (also the attacker) • gedit saves the file being edited • TOCTTOU pair: <rename, chown> • rename creates a new file • chown changes the owner of the new file to the normal user. /*create and write to temp_filename …*/ if (rename (temp_filename, real_filename) != 0){ … } chmod (real_filename, st.st_mode); chown (real_filename, st.st_uid, st.st_gid);

12. An Attack Program 1 while (!finish){ 2 if (stat(filename, &stbuf) == 0){ 3 if ((stbuf.st_uid == 0) && (stbuf.st_gid == 0)) 4 { 5 unlink(filename); 6 symlink(“/etc/passwd”, filename); 7 finish = 1; 8 } 9 } 10 } • Observation: the file owner temporarily becomes root during the vulnerability window. • Simple, brutal-force.

13. Event Analysis of vi Exploit on a Uniprocessor

14. Agenda • Background about TOCTTOU and the vulnerabilities with vi and gedit • A probabilistic model for TOCTTOU attacks • Probability analysis of exploiting vi • Probability and event analysis of exploiting gedit • Parallelizing the attack program on a multiprocessor • Conclusion

15. Some Definitions for the Probabilistic Model • Window of Vulnerability: the time interval between check and use (e.g., <open, chown>). • Attack pattern: {detection}+ [attack] • detection can be run 1 or more times • attack can be run 0 or 1 time • Three process states • Suspended: unable to run (relinquishing CPU) • Scheduled: able to run (using CPU) • Finished: finished the attack actions (symbolic link replacement, etc)

16. A Probabilistic Model for Predicting TOCTTOU Attack Success Rate P (attack succeeds) = P (victim suspended) * P (attack scheduled | victim suspended) * P (attack finished | victim suspended) + P (victim not suspended) * P (attack scheduled | victim not suspended) * P (attack finished | victim not suspended) • P (attack succeeds) on a multiprocessor is not less than that on a uniprocessor, because of the second part of the equation. • P (attack scheduled | victim not suspended) = 0 on a uniprocessor • Success gain due to the second part may become significant when P (victim suspended) is very small. • But wait, can the attack finished?

17. P (attack finished | victim not suspended) The answer = • D = detection time, L = t2 - t1 (Laxity) • t1 = the earliest start time for a successful detection • t2 = the latest start time for a successful detection leading to a successful attack

18. Agenda • Background about TOCTTOU and the vulnerabilities with vi and gedit • A probabilistic model for TOCTTOU attacks • Probability analysis of exploiting vi • Probability and event analysis of exploiting gedit • Parallelizing the attack program on a multiprocessor • Conclusion

19. Success Rate of Attacking Vi on a Uniprocessor • Between 1.5% and 18% • Approaches 0 when file size approaches 0 while ((fd = mch_open((char *)wfname, …) /* writing to wfname using fd…*/ chown((char*)wfname, st_old.st_uid, st_old.st_gid);

20. Success Rate of Attacking Vi on a SMP • 100% for files with size >=20KB • L >> D • 96% for files with 1 byte • L and D become close • Attack may not be scheduled

21. Agenda • Background about TOCTTOU and the vulnerabilities with vi and gedit • A probabilistic model for TOCTTOU attacks • Probability analysis of exploiting vi • Probability and event analysis of exploiting gedit • Parallelizing the attack program on a multiprocessor • Conclusion

22. gedit Attack Success Rates • 0 on a uniprocessor • 83% on a SMP (2 x 1.7G CPUs, 512MB memory) • The delay between rename and chmod is an important contributing factor to L. It is 43 microseconds on the SMP. Table: L and D values in microseconds (SMP) if (rename (temp_filename, real_filename) != 0){ … } chmod (real_filename, st.st_mode); chown (real_filename, st.st_uid, st.st_gid);

23. gedit Attack on a Multicore • 2 x 3.2G dual-core CPUs with HT, 4GB memory • No success at all ! • Why ?

24. New Observation on the gedit Attack • CPU is a necessary but not sufficient condition for a successful attack • Semaphore on the shared file is another necessary condition • The race between gedit and the attacker for the semaphore decides the attack result • The delay between stat and unlink of the attacker is 17 us. • The delay between rename and chmod is now only 3 us. • There is a 6 us trap (due to page fault) within the 17 us of the attacker.

25. Rethinking the gedit Attack Program 1 while (!finish){ 2 if (stat(filename, &stbuf) == 0){ 3 if ((stbuf.st_uid == 0) && (stbuf.st_gid == 0)) 4 { 5 unlink(filename); 6 symlink(“/etc/passwd”, filename); 7 finish = 1; 8 } 9 } 10 } • There is a trap when the true branch of statement 3 is taken, because unlink is never invoked before by the attacker … • Linux kernel dynamically maps shard libraries (e.g., libc) into an application’s address space.

26. The Solution… • Proactively invoke unlink to remove the trap. 1 while (!finish){ /* argv[1] holds filename */ 2 if (stat(argv[1], &stbuf) == 0){ 3 if ((stbuf.st_uid == 0) && (stbuf.st_gid == 0)) 4 { 5 fname = argv[1]; 6 finish = 1; 7 } 8 else 9 fname = dummy; 10 11 unlink(fname); 12 symlink(“/etc/passwd”, fname); 13 }//if stat(argv[1] .. 14 }//while

27. New gedit Attack on a Multicore • Started to see successes. • The trap disappeared

28. Agenda • Background about TOCTTOU and the vulnerabilities with vi and gedit • A probabilistic model for TOCTTOU attacks • Probability analysis of exploiting vi • Probability and event analysis of exploiting gedit • Parallelizing the attack program on a multiprocessor • Conclusion

29. Pipelining Attack Program • symlink needs not wait on the completion of unlink, so we can make the attack program multi-threaded • The attack can finish much earlier when the shared file is large, giving advantage when the vulnerability window is very small

30. Conclusion • A probabilistic model for TOCTTOU attacks which captures the reduced system dependability by the deployment of multiprocessors • Probability measurement and event analysis of exploiting vi and gedit, which corroborate the model and demonstrate how the attacker may utilize multiprocessors to achieve higher success rate.