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."
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:So, is vista security good enough.... (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:What does this mean? (Score:5, Interesting)
This comment has been retracted by its poster
-nB
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 title of that paper was "Randomized Sampling Clock for CPU Utilization Estimation and Code Profiling," for those who care to find it.)
Re:What does this mean? (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:Security! (Score:3, Interesting)
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 setup a difficult to detect distributed computing environment to perform massive computations in short amounts of time.
Like any concealment based vulnerability this is just a tool to be combined with others for a complete attack, but a serious issue nonetheless.
Re:A Useful Tool (Score:1, Interesting)
Re:How To Defend Against This Attack (Score:2, Interesting)
The big thing is that is (AFAIK) tracking the exact amount of time used by each process. The only proper way to do that is to do it at both each clock tick, and each volentary yield.
One other rant I have is the naming of the so called O(1) scheduler. That scheduler was apparently O(1) but only because there is a limit to the maximum number of processes. In nearly every case it is possible to construct on O(1) algorithm if the maximum number of possibilities is known in advance. Technically the algorithm's timing was some function of the maximum number of processes. Since the maximum number of processes is a compile time constant, the algorithm is constant-time.
Re:What the?! (Score:2, Interesting)
Re:Security! (Score:3, Interesting)
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 service and go somewhere else. If, on the other hand you QoS attack a server, the owner will be frustrated because performance is poor, but they will have to spend a good bit of time trying to track down WHY exactly the performance is poor, but, more importantly the users connecting to the service will have a very poor experience, and that hurts the servers owner. A user is willing to cut someone slack if the server goes down, but they're much less forgiving when the servers performance is just poor.
The process is not invisible, you are correct, but it is hard to spot. If the malicious program is named something innocuous such as srvchost.exe (check your process list in Windows, there's a ton of the suckers), or maybe httpd in linux, and the user attempts to figure out what's causing slow downs on their system, they will be looking at anywhere but these processes because they will be showing 0% CPU utilization. Also, as I said, this is only part of a proper attack, this combined with some other exploit that hides the presence of the process will be even more confusing to the user because this attack actually re-allocates the used timeslices for the process to other random processes, so to the user it looks like the entire system is just using way more CPU time than normal. Of course, if you have a root kit you can perform this re-allocation at the kernel level, but part of the point of this exploit is that it's 100% userland so has a much smaller barrier to entry.
Re:Talk about a fair share scheduler ! (Score:3, Interesting)
--Ivan
Re:What does this mean? (Score:4, Interesting)
Re:Security! (Score:1, Interesting)
The GUI is not considered to be a time critical task. Yes the spinning beach ball can be annoying, but it will eventually go away.
But have you ever noticed that even when you have beach ball going, and the system seems locked up, iTunes never skips a beat? That's because the audio playback is running in a real time thread.
Re:Security! (Score:2, Interesting)
The UI may not be time critical but there is *a lot* of beach ball spinning going on on that system. It gets old pretty quick.