Multiprocessors May Reduce System Dependability Under File-based Race

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

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

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

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

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

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

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

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

TOCTTOU Vulnerabilities in Red Hat Linux 9 [1] Tested: ~130 utilities from /bin, /sbin and /usr/bin Application vi TOCTTOU errors Possible exploit <open, chown> Changing the owner of /etc/passwd to an ordinary user gedit <rename, chown> Changing the owner of /etc/passwd to an ordinary user rpm <open, open> Running arbitrary command emacs <open, chmod> Making /etc/shadow readable by an ordinary user [1] Jinpeng Wei, Calton Pu. FAST’ 05 9

vi 6. 1 Vulnerability n The vulnerability happens when Ø Ø Ø n 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); 10

gedit 2. 8. 3 Vulnerability n Similar to the vi vulnerability Ø Ø Ø n 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); 11

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 } n n Observation: the file owner temporarily becomes root during the vulnerability window. Simple, brutal-force. 12

Event Analysis of vi Exploit on a Uniprocessor 13

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

Some Definitions for the Probabilistic Model n n Window of Vulnerability: the time interval between check and use (e. g. , <open, chown>). Attack pattern: {detection}+ [attack] Ø Ø n 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) 15

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) n P (attack succeeds) on a multiprocessor is not less than that on a uniprocessor, because of the second part of the equation. Ø n n 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? 16

P (attack finished | victim not suspended) The answer = n n n D = detection time, L = t 2 - t 1 (Laxity) t 1 = the earliest start time for a successful detection t 2 = the latest start time for a successful detection leading to a successful attack 17

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

Success Rate of Attacking Vi on a Uniprocessor n Between 1. 5% and 18% n 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); 19

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

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

gedit Attack Success Rates n n n 0 on a uniprocessor 83% on a SMP (2 x 1. 7 G CPUs, 512 MB 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); 22

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

New Observation on the gedit Attack n n 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 n The delay between stat and unlink of the attacker is 17 us. n The delay between rename and chmod is now only 3 us. n There is a 6 us trap (due to page fault) within the 17 us of the attacker. 24

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 } n n 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. 25

The Solution… n 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 26

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

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

Pipelining Attack Program n n 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 29

Conclusion A probabilistic model for TOCTTOU attacks which captures the reduced system dependability by the deployment of multiprocessors n 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. n 30