1 / 30

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

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. System Dependability: Brief History.

talia
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related