Multiprocessors may reduce system dependability under file based race condition attacks
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

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


  • 73 Views
  • Uploaded on
  • Presentation posted in: General

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.

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.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.


It s much easier to attack tocttou vulnerabilities on multiprocessors

It’s Much Easier to Attack TOCTTOU Vulnerabilities on Multiprocessors


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.


Event analysis of vi exploit on a uniprocessor

Event Analysis of vi Exploit on a Uniprocessor


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.


  • Login