multiprocessors may reduce system dependability under file based race condition attacks
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


  • 96 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


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