1 / 29

Secretly Monopolizing the CPU Without Superuser Privileges

Secretly Monopolizing the CPU Without Superuser Privileges. In a nutshell. We implement a “cheat” utility: shell~/> cheat 90% program. Unlike a rootkit. e.g. “cosmic rays attack” on JVMs [S&P 2003]. obtain root & install rootkit: secretly ctrl all resources. cheat

nayda-fisher
Télécharger la présentation

Secretly Monopolizing the CPU Without Superuser Privileges

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secretly Monopolizing the CPU Without Superuser Privileges

  2. In a nutshell • We implement a “cheat” utility: shell~/>cheat 90% program

  3. Unlike a rootkit

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

  5. Concealment: how?

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

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

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

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

  11. Monopolizing: how? • 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!

  12. “Interactivity” makes it worse • Turns out monopolizing is possible even without concealment capabilities… • Scheduling for ‘interactivity’ raises ugly head:

  13. Vulnerability spectrum

  14. The cheat algorithm 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… } }

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

  16. ‘Top’ snippet

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

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

  19. Conclusions • 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]

  20. “Cheat” attack - Impact • Linux scheduler: Ingo Molnar, maintainer of the Linux Scheduler: [ From the CFS-scheduler announcementpeople.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) • 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 • “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. Backup…

  23. Cheat accuracy achieved cheat rate [%] desired cheat rate [%]

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

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

  26. The cheat-server protocol

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

  28. Binary instrumentation slowdown block trace function instruction selected function instrumentation granularity

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

More Related