Presentation is loading. Please wait.

Presentation is loading. Please wait.

1/19 Secretly Monopolizing the CPU Without Superuser Privileges IBM Watson, NY-Dan Tsafrir Hebrew University, Jerusalem-Yoav Etsion Hebrew University,

Similar presentations


Presentation on theme: "1/19 Secretly Monopolizing the CPU Without Superuser Privileges IBM Watson, NY-Dan Tsafrir Hebrew University, Jerusalem-Yoav Etsion Hebrew University,"— Presentation transcript:

1 1/19 Secretly Monopolizing the CPU Without Superuser Privileges IBM Watson, NY-Dan Tsafrir Hebrew University, Jerusalem-Yoav Etsion Hebrew University, Jerusalem-Dror Feitelson

2 2/19 In a nutshell We implement a “cheat” utility: shell~/> cheat 90% program (2) concealment aspect(1) hostile aspect - ‘program’ appears as consuming 0%... - …on some systems, when using tools like top, ps… - ‘program’ would get 90% of the CPU cycles… - …regardless on any background load

3 3/19 Unlike a rootkit cheatrootkit any non-privileged user can easily do it requires superuser access concealment-capabilities (being able to secretly use the CPU) hostile action (being able to monopolize the CPU) hostile-action (breaking in & installing the rootkit) concealment-capabilities (being able to secretly use any computer resource)

4 4/19 The privileges-conflict axis Attackers/defenders conflict often revolves around 1) Privileges of using resources, and 2) How long these privileges last general limited cheat secretly ctrl one resource (can envision rootless rootkit) obtain root & install rootkit: secretly ctrl all resources e.g. “cosmic rays attack” on JVMs [S&P 2003] privileges-conflict axis

5 5/19 Concealment: how? cheatrootkit any non-privileged user can easily do it requires superuser access concealment-capabilities (being able to secretly use the CPU) hostile action (being able to monopolize the CPU) hostile-action (breaking in & installing the rootkit) concealment-capabilities (being able to secretly use any computer resource)

6 6/19 Ticks = periodic hardware interrupts OSs wake up HZ times a second: Since the 1960s (60Hz, like the grid) [Dijkstra; the “THE” system; CACM’68] Operating System “ticks” FreeBSDWindowsLinuxOS HZ 1ms10ms4ms1ms10msevery

7 7/19 The tick-handler Tick-handler’s activities: 1) Deliver due alarm signals 2) CPU accounting 3) Initiating preemption (for multitasking) 4)... Kernel’s “main loop”; its way to maintain control

8 8/19 Example movie player [display every 20ms] nuclear simulator kerneltick [1ms] sleeprunbilln+1 sleeprunbilln+2 … sleeprunbilln+19 - display next frame - request n+40 - yield suspended - bill - deliver alarm - switch n+20 sleeprunswitch sleeprunbilln+21 seeprunbilln+22 …

9 9/19 Concealment: how? time Run when OS not looking… (Not as easy as it sounds) tick ntick n+1 tick n+2 tick n+3 cheater runs

10 10/19 Misaccounting: if we pull it off time The ‘honest’ process appears consuming 100% tick ntick n+1 tick n+2 tick n+3 cheater runs honest

11 11/19 The negative-feedback scheduling-principle - Running reduces priority to run more This principle guarantees 1) Fair allocation of CPU 2) Chronic sleepers (like emacs) get high priority Latter largely what makes editors responsive - And indeed, our cheater looks like an editor! Monopolizing: how?

12 12/19 “Interactivity” makes it worse Turns out monopolizing is possible even without concealment capabilities… Scheduling for ‘interactivity’ raises ugly head: recenttraditionalscheduling: multimedia, soft realtime, movie players, games editors, chronic sleepers workload: highlowCPU demand: sleep frequency (lots of deadlines) sleep duration (negative feedback) prioritize by:

13 13/19 Vulnerability spectrum

14 14/19 void cheat_attack( double fraction) { work = fraction * cycles_per_tick(); nanosleep(0);// sync with tick tick_start = get_cycles(); while( 1 ) { now = get_cycles(); if( now - tick_start ≥ work ) { nanosleep(0); // avoid bill tick_start = get_cycles(); } // do some short work here… } } The cheat algorithm

15 15/19 Evaluation 80%-cheater vs. honest-process tick time [ms] time [sec] tick time [%] cheater honest other used CPU [ms] billed CPU [ms]

16 16/19 ‘Top’ snippet COMMANDTIME%CPUSTATPRUSERPID honest0: R21dants5522 top0: R16dants5508 csh0: S16dants5246 csh0: S16dants5259 bm-noklog.sh0: S16dants5509 … cheater0: S15dants5521

17 17/19 Cycle-accurate billing tick time [ms] billed CPU [ms] before cheater honest time [sec]used CPU [ms] after tick time [ms] billed CPU [ms] honest cheater time [sec]used CPU [ms]

18 18/19 Curbing interactives preference time [ms]used CPU [ms] billed CPU [ms] tick time [ms] cheater ( 50.02% ) honest ( 49.97% ) other ( 0.01% ) all the datazoom in

19 19/19 Cheating allows unprivileged users to - seize CPU, often secretly To protect against cheating, one must 1) maintain accurate-enough info 2) incorporate info in scheduler ( unlike Solaris, XP) 3) do it carefully ( unlike Linux2.6, FreeBSD/ULE, XP) OS trend: prioritize based on sleep-frequency - plays straight to the hands of cheaters - probably fruitless - alternative: explicitly track relevant devices [NOSSDAV’04, TOMCCAP'06] Conclusions

20 “Cheat” attack - Impact Linux scheduler: Ingo Molnar, maintainer of the Linux Scheduler: 'attacks' that exist today [ From the CFS-scheduler announcement people.redhat.com/mingo/cfs-scheduler/sched-design-CFS.txt ] “Due to its design, the CFS scheduler is not prone to any of the 'attacks' that exist today against the heuristics of the stock scheduler”

21 “Cheat” attack - Impact Amazon’s “Elastic Compute Cloud” (EC2) Scheduler vulnerabilities & coordinated attacks in cloud computing –F. Zhou, M. Goel, P. Desnoyers, & R. Sundaram, “Scheduler vulnerabilities & coordinated attacks in cloud computing”, Northeastern U., Boston Technical Report, 2010 –Subverting Xen hypervisor with the cheat attack reported this vulnerability to Amazon; they have since implemented a fix –“Following the responsible disclosure model, we have reported this vulnerability to Amazon; they have since implemented a fix that we have tested and verified”

22 22/19 Backup…

23 23/19 Cheat accuracy desired cheat rate [%] achieved cheat rate [%]

24 24/19 Effect of background load all are honestone is 80%-cheater number of competing processes CPU [%] all the others one competitor all the others on 80% cheater

25 25/19 Running unmodified programs Two approaches: 1) Cheat server 2) Binary instrumentation

26 26/19 The cheat-server protocol

27 27/19 Stealing a cluster with a P-III cluster size [nodes; log scale] CPU [%] sum of 60%-cheaters (one per node) sum of honest (10 per node)

28 28/19 Binary instrumentation instrumentation granularity slowdown instruction block trace function selected function

29 29/19 Protecting against cheating: degrees of accuracy Two approaches 1) Solaris & Windows way - Account for every kernel entry/exit (which e.g. slows down syscalls path) 2) BSD & Linux way - Accounting by tick-handler only (inaccurate) Compromise - Accounting only upon a context-switch - Price: context-switch slower by 5%


Download ppt "1/19 Secretly Monopolizing the CPU Without Superuser Privileges IBM Watson, NY-Dan Tsafrir Hebrew University, Jerusalem-Yoav Etsion Hebrew University,"

Similar presentations


Ads by Google