multiprocessors may reduce system dependability under file based race condition attacks n.
Download
Skip this Video
Download Presentation
Multiprocessors May Reduce System Dependability Under File-based Race Condition Attacks

Loading in 2 Seconds...

play fullscreen
1 / 30

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


  • 97 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Multiprocessors May Reduce System Dependability Under File-based Race Condition Attacks' - talia


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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
multiprocessors boon or bane
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.
agenda
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
definition and scope
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
sendmail example
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

sendmail vulnerability an example
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!

tocttou vulnerabilities in red hat linux 9 1
TOCTTOU Vulnerabilities in Red Hat Linux 9 [1]

Tested:

~130 utilities from /bin, /sbin and /usr/bin

[1] Jinpeng Wei, Calton Pu. FAST’05

vi 6 1 vulnerability
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);

gedit 2 8 3 vulnerability
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);

an attack program
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.
agenda1
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
some definitions for the probabilistic model
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)
a probabilistic model for predicting tocttou attack success rate
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?
p attack finished victim not suspended
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
agenda2
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
success rate of attacking vi on a uniprocessor
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);

success rate of attacking vi on a smp
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
agenda3
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
gedit attack success rates
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);

gedit attack on a multicore
gedit Attack on a Multicore
  • 2 x 3.2G dual-core CPUs with HT, 4GB memory
  • No success at all !
  • Why ?
new observation on the gedit attack
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.
rethinking the gedit attack program
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.
the solution
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

new gedit attack on a multicore
New gedit Attack on a Multicore
  • Started to see successes.
  • The trap disappeared
agenda4
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
pipelining attack program
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
conclusion
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.