Secretly Monopolizing the CPU Without Being Root 250
An anonymous reader writes "This year's
Usenix security symposium
includes a
paper
that implements a "cheat" utility, which allows any non-privileged user to
run his/her program, e.g., like so 'cheat 99% program'
thereby insuring that the programs would get 99% of the CPU
cycles, regardless of the presence of any other applications in the
system, and in some cases (like Linux), in a way that keeps the program
invisible from CPU monitoring tools (like 'top'). The utility exclusively
uses standard interfaces and can be trivially implemented by any
beginner non-privileged programmer. Recent efforts to improve the
support for multimedia applications make systems more susceptible to
the attack.
All prevalent operating systems but Mac OS X are vulnerable, though by
this kerneltrap story,
it appears that the new CFS Linux scheduler attempts to address the
problem that were raised by the paper."
A Useful Tool (Score:5, Funny)
Re:A Useful Tool (Score:4, Informative)
Re:A Useful Tool (Score:5, Funny)
Re:A Useful Tool (Score:4, Insightful)
Much easier to just renice your root shell automatically at login
Re: (Score:3, Insightful)
Google-cache article (Score:3, Informative)
Re:Google-cache article (Score:5, Informative)
it works by avoiding running during the exact moment of a clock tick (which would be the moment when CPU usage per-process is checked). to start running immediately after a clock tick is (apparently) easy, but to stop before the next tick is harder. the paper suggests using some kind of get_cycles assembly instruction to count how many CPU cycles there are per clock tick, and use that number to gauge when the next clock tick is going to occur by counting how many CPU cycles have elapsed.
Re:Google-cache article (Score:4, Funny)
it works by avoiding running during the exact moment of a clock tick (which would be the moment when CPU usage...
--Uhm... (looks at watch...) Say, I really don't have time for wordy summaries... could you maybe cut this down into about 10 words or less? Hurry it up! I ain't got all day!
Re:Google-cache article (Score:5, Funny)
Re: (Score:2)
k thx bye (Score:2)
NEXT!
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
gnome (Score:3, Funny)
What the?! (Score:5, Funny)
#include
int main(int argc, char *argv[])
{
while (1) {}
return 0;
}
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Wait. Something's wrong here.
Re: (Score:2)
Re: (Score:2, Insightful)
$
But that really isn't the point here. This lets your run any arbitrary program, using max resources, (despite scheduling), AND hide the fact that the process is using *any* resources
Re: (Score:2, Interesting)
Re: (Score:2)
while(1)
fork();
Re: (Score:3, Informative)
Per-user process limits (Score:3, Insightful)
Re: (Score:3, Insightful)
I guess they just put on a nproc limit on each user. It's just a trivial security measure against simple fork bombs. Assuming your Linux system uses PAM (most modern distros do), take a look at
Re: (Score:2)
Re: (Score:2)
x...<-joke
/\
o
+...<-you
The plural of CPU is CPUs, not CPU's. CPU's is the possessive form of CPU.
Re: (Score:2)
Grammar Nazis the world over, today you failed your mission. Let us give one minute of silence for remembrance.
Re: (Score:2)
But not in the original usage (at least in the place the previous post was complaining about). You can't use a complete sentence as a noun.
Re: (Score:2)
No, it isn't. It is one of the most misused uses of the apostrophe, but it is not in any way correct English. The plural of an acronym is formed by adding a lowercase "s". Don't believe me? Look it up.
Re: (Score:2)
"Correct" makes sense when talking about latin because it is not a natural language - latin is a logic game; english, however, is used to satisfy the fashions and fads of any given week and changes at the demand of its users.
Old news (Score:4, Informative)
If you check the linux kernel mailing list for Vassili Karpov, you should find test cases that demonstrate this behavior and tools for monitoring actual CPU usage for a variety of platforms, though I notice no mention of any of that in the paper.
See http://www.boblycat.org/~malc/apc/ [boblycat.org] for the tool and 'invisible CPU hog' test case.
Re:Old news (Score:5, Informative)
ok (Score:3, Interesting)
Yes, I'm kidding. Please don't post a long reply explaining how renice differs from this cheat thing. It isn't necessary.
Re: (Score:2)
It's worse than you think... (Score:2)
Now I have no excuse to avoid working on the dbase (Access and VBA, ugh)
I was an "Access Developer" for a while, even a consultant doing the same (yes, I would sell my soul for a dollar)
Now I have a *Real* job as part of a programming team working with a *mostly* real RDBMS.
you will be in my prayers, brother-in-arms.
It's worse than that, I'm a software development major in college, working as an intern consultant. I don't even know VB, but using Real Languages gives me enough to fly by the seat of my pants. The dbase is done by some guy who can no longer be found, writes spaghetti code and has a fondness for loops while doing lookups. It's been 'upgraded' from Access '95, to '97, to 2K, yet I'm not allowed to just drop the thing into SQL Server and use .NET to put a new front end on it. It is the bane of my existe
It was news,... in 1980 (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Not exactly. This is a technique that will, in prinicple, work with any scheduler that prioritizes tasks on the basis of time ticks previously used by the task. That turns out to be most of them. The technique does not require being an I/O driver, other special task, or having unusual user priviliges.
So yes, it IS news.
First announced exploit.. (Score:2, Funny)
This year's Usenix security symposium includes a paper that implements a "cheat" utility, which allows any non-privileged user to run his/her program, e.g., like so 'cheat 99% program' thereby insuring that the programs would get 99% of the CPU cycles, regardless of the presence of any other applications in the system, and in some cases (like Linux), in a way that keeps the program invisible from CPU monitoring tools (like 'top').
Next up, a virus which senses bad grammar and punishes you by using 99% of
Re:First announced exploit.. (Score:5, Funny)
Do you think this might be related to that incident where thousands of English teachers all burst into flames moments after the first SMS-enabled phone was released?
Re: (Score:2)
NO CARRIER
Sounds great in some respects. (Score:2)
Curious how this works.
Re: (Score:3, Informative)
Talk about a fair share scheduler ! (Score:5, Insightful)
In my days (yes, I'm an old fart) - the schedulers had basic principles :
- Voluntary yielding led you to get accounted for the time you spent running.
- You could stay in the interactive queue for only a certain amount of time. After some amount of time had passed (a few secs) you were either bumped to non-interactive if you were running (with longer time slices but lower priority) or removed off the scheduler list for good (if the time spent there was idling). They had a special 'idle but interactive' (not eligible for dispatching) queue for that.
- Scheduling a new task restarted a new time slice
That particular scheduler even had a 3 queue system so that if you got accidentally bumped into the non-interactive queue or if your process was semi-interactive you had a better chance of gaining interactive status again. And they had a 'really' not interactive queue for those CPU hogging processes.
Of course this requires the hardware to have a precise timing feature (something with a granularity that is finer than the process interleaving time slice time and ideally in the magnitude of instruction execution). And this scheduler wasn't using time sampling and time quantums.. (but something more like the OSX timer on demand paradigm).
--Ivan
Re: (Score:2)
Re: (Score:3, Interesting)
--Ivan
How It Works (Score:5, Informative)
This is accomplished by sleeping for a fixed amount in between OS clock ticks. The timeline looks like this:
Re: (Score:2, Funny)
Re: (Score:2)
Doing the billing on a clock tick sounds like a recipe for failure.
Re: (Score:2)
problem. But to do that properly and with decent accuracy
would require 64 bit counters to nanosecond level.
Re:How It Works for Kids (Score:2)
Your goal is to run as quickly as you can towards me. When I turn and face you and say "Red Light" you must stop moving and if I catch you moving I make you start over from the beginning. When I'm not looking and say "Green Light" you can move again.
In this case, the goal is to cover the greatest total distance instead of just reaching my position; so we could adapt it from running to eating: The "winner" is the one who eats the most and the losers end up hungry.
Re: (Score:2)
A Car analogy? I got nothin.
Back at NYIT we hacked the "nice" command... (Score:3, Funny)
We changed nice so that whenever this particular user ran it, it lowered his priority by exactly as much as he was attempting to raise it.
He stopped coming to work soon after that. I suppose he had the last laugh though -- NYIT continued to pay him for another six months.
Thad
Re: (Score:2)
And, you do realize that "nice" with a positive argument lowers priority.
Re: (Score:2)
What system is this that allows "nice" to raise priority for users other than root?
I don't know the answer, but there are a LOT of UNIX-like operating systems out there, and contrary to belief, they don't all work the same.
sweet! (Score:2)
*BSD? (Score:2)
Here's the difference (Score:3, Informative)
What 'saved' the Mac OS was its different use of timing triggers. "All" other OS'es use one common steadily ticking clock as a dealer of time slots. This allows the cheat to "skip to the start of the line (queue)" every time it's had its turn.
OTOH, the Mac uses a stack of alarms set to specific points in the future, and polled in order as they occur. So the difference on Mac OS is that there's no skipping the queue, it's rather "there is no queue, we'll call you when it's your turn
Re: (Score:2)
FreeBSD for being the closest relative
MacOS is not FreeBSD. It's got a Mach kernal.
I know, but in broad terms (especially in peoples' minds) it's still seems to be "the closest" (just as "the best" Lotus Notes database need not be "a good" database ;-p ).
and OpenBSD for its goal of trying "to be the #1 most secure operating system"
This looks like an efficiency issue, not a security issue.
And yet, hogging the CPU might be indistinguishable from a DDOS -- at least in the perspective of other users.
Re: (Score:2)
Yeah but neither Mac OS X nor FreeBSD runs in the mind at this time. The BSD subsystem in Mac OS X is an optional install, a Unix compatibility layer. The kernel is called xnu and although it is descended from Mach it is also descended from Mac OS and NeXT and also it is not a microkernel.
Re: (Score:2)
OS X has a hybrid kernel, XNU, a major part of it based on Mach, as well as incorporating sizable bits of FreeBSD, plus Apple bits that are not related to either one. It's not Mach, and it's not FreeBSD.
Linux 2.6.21 is probably immune too (Score:5, Informative)
According to the paper, the reason Mac OS X is not vulnerable is that it uses one-shot timers scheduled for exactly when the next event needs to occur, rather than periodic "ticks" with a fixed interval between them. The "tickless idle" feature introduced in Linux 2.6.21 (currently only on x86, I believe) takes the same approach, and very possibly makes Linux immune too.
(Ironically, immediately after discussing OSX's ticklessness, the paper mentions that "the Linux 2.6.16 kernel source tree contains 8,997 occurrences of the tick frequency HZ macro, spanning 3,199 files", to illustrate how difficult it is to take a tick-based kernel and make it tickless. But those kernel hackers went and did it anyway.)
The tickless feature isn't yet implemented on all architectures that Linux supports, though. I think AMD64 support for it is supposed to come in 2.6.23, along with the new CFS scheduler.
Re:Linux 2.6.21 is probably immune: RDTSC? (Score:3, Informative)
Fixed recently in Linux (Score:5, Informative)
The CFS additionally removes the interactivity boost in favor of giving interactive tasks no extra time but rather just quick access to their available time, which is what they really benefit from.
How To Defend Against This Attack (Score:2)
Re: (Score:2, Interesting)
Summary and Questions (Score:5, Informative)
Most OSes (Linux, Solaris, Windows but not Mac OS X) are tick-based. This means that the kernel is called from hardware periodically (this is the "HZ" value you set in the Linux kernel). Some of them (Linux) simply check which process is running at each tick and compute statistics based on that ("sample-based statistics"). This means that the process running when the tick happens is billed for the entire period of the tick.
Since ticks are typically "long" (typically 1-10 ms on Linux) more than one process may run during this period. In other words, using this approach leads to inaccuracies in the process billing. If all programs "play by the rules" this works quite well on average though.
Next thing: the classic schedulers typically maintain some sort of "priority" value for each process, which decreases whenever the process is running and increases when it's not. This means that a process runs for some time, its priority decreases, and then another process (which hasn't been running for some time) takes over.
You can exploit that by always sleeping when a tick happens and running only in-between ticks. This makes the kernel thinks that your process is never running and give it a high priority. So, when your process wakes up just after a tick happened, it will have a higher priority than most other processes and be given the CPU. If it goes to sleep again just before the next tick, its priority will not be decreased. Your process will (almost) always run when it wants to and the kernel will think that it's (almost) never running and keep its priority high. You win!
Another aspect is that modern kernels (at least Linux and Windows) distinguish between "interactive" (e.g. media players) and "non-interactive" processes. They do so by looking how many times a process goes to sleep voluntarily. An interactive program (such as a media player) will have many voluntary sleeps (e.g. inbetween displaying frames) while a non-interactive program (e.g. a compiler or some number crunching program) will likely never go to sleep voluntarily. The scheduler gives the interactive programs an additional priority boost.
Since the cheating programs go to sleep very often (at every tick) the kernel thinks they're "very interactive", which makes the situation worse.
Some of the analyzed OSes - even if tick-based - do not use sample-based statistics in the kernel but they do use sample-based statistics for scheduling decisions. So the kernel sees that a process is taking more CPU than it should but it will still keep on scheduling it.
Mac OS X is not affected because it has a tickless kernel (e.g. without periodic interrupts). Because of that sample-based statistics don't work and it has to use accurate statistics, which make it unaffected by the bug.
This bug can be exploited to (at least)
- get more CPU than you're supposed to
- hinder other programs in their normal work
- hide malicious programs (such as rootkits) which do work in the background
Here's a list with the OSes (this USED TO BE a nicely formatted table, but the darned Slashdot "lameness filter" forced me to remove much of the nice lines and the "ecode" tag collapses whitespace).
OS, Process statistics, Scheduler decisions, Interactive/non-interactive decision, Affected
Linux, sample, sample, yes, yes
Solaris, accurate, sample, ?, yes
FreeBSD 4BSD, ?, sample, no?, yes
FreeBSD ULE, ?, sample, yes, yes
Windows, accurate, sample, yes, yes
Mac OS X, accurate, accurate, not needed?, yes
I guess that Mac OS X doesn't need a interactive/non-interactive distinction because of its different (tickless) approach. I assume that interactive applications can (implicitly or explicitly) can be recognized as such in a different way. Does anyone have more information on that?
How does tickless Linux compare? What abo
Re:Summary and Questions (Score:4, Informative)
Vista changed to counting actual CPU cycle count register. The goal was to prevent process starvation in high I/O situations, but it also addresses this issue as well.
http://www.microsoft.com/technet/technetmag/issue
MOD PARENT UP (Score:2)
This, and the earlier comments about the latest Linux versions becoming tickless are ruining my plans for making a thumbdrive of nifty utilities.
Clever but what loss? (Score:3, Insightful)
A very simple patch is to issue RDTSC instructions at process restart and blocking syscall to count the cycles actually used. That way the extensive tick-code doesn't need to be modified.
Malware (Score:2)
Re: (Score:2)
Re: (Score:2)
As for users on a cluster/shared host, that becomes an administrative issue. A thief can be caught (process watchdog on HD or ethernet interrupts) and booted. Probably a significant punishment to the thief, most of whom don't need cycles. Those who do are tied to software.
Way back in the '90s (Score:2, Interesting)
Chris Torek gave a presentation at UseNIX about how a constant quantum could result in a process having its CPU usage unaccounted.
His solution was to use a randomized quantum. Not unique per process, but randomized when the kernel starts running each process. That gave you a better accounting of the CPU time (statistics, doncha know :)), but also made this kind of attach much, much harder.
I'm somewhat disappointed that I did not see Chris and Steven's paper referenced in this one. (I believe that the t
Why is this new? (Score:3, Insightful)
I remember seeing this done on the VAX/VMS mainframe back in 1987. In that environment, it simply meant that you kept track of your timeslice and voluntarily gave it up before the scheduler took it away from you. That meant you got put at the top of the run queue, and unless someone else was doing the same thing, you were the next program to run. Voila... 99% CPU for you!
Of course, ordinary users were given a limited amount of CPU time (as well as connect time, disk space, etc), so for the ordinary student, this just meant they used it up in a day or two instead of having a whole month. But then again, for class accounts, they could usually beg for more.
Under unix variants, one could do the same by implementing cpu quotas at the user level. I've seen network packet quotas, and I'm sure someone out there has done cpu quotas along the same lines.
Re:What does this mean? (Score:5, Informative)
Re:What does this mean? (Score:5, Funny)
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
You gun-toting marxist redneck zealot astroturfers make me sick!
Inevitable reply (Score:5, Funny)
Re:Inevitable reply (Score:5, Funny)
Re: (Score:3, Interesting)
We already have that. They're called McAfee Automatic Update and Windows Automatic Update.
God dammit, I hate those things. I turn on my office computer in the morning, and just let it sit for ten minutes because it's otherwise useless. (I turned-off Windows Automatic Update, but McAfee was more than happy to fill its shoes in needless resource hogging.)
Re: (Score:2)
Re:What does this mean? (Score:5, Insightful)
Re:What does this mean? (Score:5, Interesting)
This comment has been retracted by its poster
-nB
Re:What does this mean? (Score:5, Insightful)
Hmmm... (Score:2)
Re:What does this mean? (Score:4, Interesting)
Re: (Score:2)
The ability to edit one's comments would be nice, but I'd only want to see that kind of feature if you could actually review
Re: (Score:3, Interesting)
That isn't likely to happen without a change in attitude due to both starting furthur behind and progressing more slowly. The current malware situation looks like bad SF and a morality tale of what happens when you allow really stupid things to happen (eg. letting arbitrary code embedded in images run - hopefully that person was dismissed from Microsoft).
Re: (Score:2)
Re: (Score:3, Insightful)
Of course not. It shows that OS research work is likely to be done on a Unix of some sort where the source code is available for anaylsis
TFA points out that Windows is just as vulnerable to these cheats as BSD, Linux and Solaris. The cheat works by releasing the CPU just before the end of a time tic
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
If you just want to DoS the box as a local user (which is all this lets you do, from a security standpoint), then there are much easier ways of doing this on OS X via the VM subsystem.
You're missing the point here. Because the CPU accounting is off it's possible to do a QoS attack on a box rather than a DoS, that's virtually impossible to detect as the end user. From his or her standpoint, the system will be sluggish, but because of the way the attack works various random processes will seem to be taking up all that extra slack so that most likely no one process will appear to be hogging the CPU.
There's also the possibility when combined with a worm or rootkit, as well as a bot net to
Re: (Score:3, Interesting)
I guess I'm not hip, but what exactly is the difference between a QoS attack and a DoS attack? I mean severly degrading the quality of the service potentially up to the point of denying it *is* a DoS attack.
A DoS attack is an extreme form of QoS. If you perform a QoS attack on someone their performance is reduced, but the system is still usable, where as in a DoS the goal is to make the system totally unusable. In some ways a QoS is even more effective than a DoS because it's more subtle and causes more frustration. If for instance a website gets DoSed the owner is upset and will try to get someone to investigate and shutdown if possible whoever is DoSing them, and the users simply cannot connect to the serv
Re: (Score:3, Funny)
I'll prove you wrong as soon as that stupid spinning beach ball of death lets me do something.
Re:The "sue" command (Score:5, Funny)
Re: (Score:2, Funny)
What a scary, scary thought...
Re: (Score:2)