[Infowarrior] - Security paper shows how application can steal CPU cycles

[Richard Forno]

Security paper shows how application can steal CPU cycles

By Jeremy Reimer | Published: July 11, 2007 - 11:06PM CT

http://arstechnica.com/news.ars/post/20070711-security-paper-shows-how-appli
cations-can-steal-cpu-cycles.html

The annual Usenix security symposium is a gathering place for all kinds of
ideas: those on how to stop security flaws and those about what kinds of new
security issues may emerge in the future. A neat example of the latter was
presented by Dan Tsafrir, Yoav Etsion, and Dror G. Feitelson in their paper
(PDF) entitled "Secretly Monopolizing the CPU Without Superuser Privileges."
The team presented a proof-of-concept program for Unix-based
systems‹although it could theoretically be adopted for any modern
multitasking operating system‹that allows a specified task to "cheat" and
take more CPU cycles than the OS would normally allow it to have.

Security breaches fall into one of two categories: either the action is
hostile (a program does something the user does not want, such as sending
out spam), or it is concealing (the program attempts to conceal hostile
actions from being discovered by the user). Most traditional concealing
actions, such as rootkits, depend on having full administrative access to
the computer in order to run.

The utility described in the paper, dubbed "cheat," can run as a regular
non-administrative user. In theory, a task could hide itself perfectly by
arranging for its process to run just after the CPU interrupt "tick" fires
(most operating systems generate this tick from the hardware-based clock and
fire it once every few milliseconds) and goes to sleep just before the next
tick. Because of this, the standard operating system task accounting
procedures would never notice that the process is even running. All normal
OS methods of tracking tasks‹for example, the "top" command in Linux and
Unix, or the Windows Task Manager‹will fail to display the cheating task,
and this is without any modification of the operating system.

The paper goes on to say that arranging a task to always run at such
convenient times without administrative (superuser) access is "technically
impossible;" instead, several workarounds are demonstrated that allow
"cheat" to come close to this ideal behavior without always achieving it.
The program uses a more fine-grained timer than the standard operating
system interrupt, called a cycle counter: a CPU instruction that can be
accessed at the user level by issuing an assembly command.

Seven different operating systems were examined in the paper as potential
platforms for the attack. Of the seven, only Mac OS X was found to be immune
to the "cheat" attack; not because of a superior security architecture, but
because it uses a different scheduling algorithm for its timers. Other
operating systems that would be safe from attack include real-time OSes such
as QNX, which guarantee execution of programs within a certain time limit.

The exploit may or may not find its way into use in the malware world. While
it is handy to avoid detection in task lists, using up most of a user's CPU
cycles will have the very visible result of creating a slow computer, which
would raise most people's suspicion levels. Still, programs could be written
to cheat just a little bit, and such applications would be extremely hard to
detect and remove. The authors found that they could protect the operating
system against such attacks, but at the cost of performance.