Slashdot Mirror
Secretly Monopolizing the CPU Without Being Root
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."
Back in my day we called it renice.
Yes, I'm kidding. Please don't post a long reply explaining how renice differs from this cheat thing. It isn't necessary.
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).
Why not leave the post but allow a "retracted" tickbox? Thus at least the owner of the comment can effectively say "I was wrong, boneheaded, whatever" without having to post another comment and wait two minutes to do it? and all that shows up it a one-liner under the comment:
This comment has been retracted by its poster
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
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.)
I'm assuming that we're saying that this application can get 99% of the time-slices on an otherwise occupied system, starving other tasks for resources.
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.)
Does it make you happy you're so strange?
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.
Curiosity was framed, Ignorance killed the cat.
True, but you can set limits on the number of processes per user and other stuff to stop a fork bomb. On Linux with PAM these are set in /etc/security/limits.conf, appropriate limits vary depending on the resources available to the machine. A good admin should be aware of fork bombs and make the appropriate configuration to stop them.
The second one is obviously the better one. I think this is basically what the CFS does. (the following is my understanding. It may be wrong) For processes it figures out what amount of time each process should have (based on the the number of processes. It tracks how much time each process is owed (in the case of 5 processes each deserves 1/5 of the total processor time). It subtracts the time used on each scheduler event (clock tick or voluntary yield.) Each clock tick the scheduler transfers control to the process owed the most time (but there is a minimum number of clock ticks before mandatory switching to prevent cache thrashing.) I presume voluntary yielding has some form of impact on the time owed amount, or else idling processes would always stay at the top of the list. Obviously there is more complications, such as nice levels, and everything.
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.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
Yeah, it surprised me too when I ran it for the first time. it is easy enough to fix (can't remember right now, but i recall something about a "limits" file) but should hint that that default is set too high.
"Hate is baggage. Life's too short to be pissed off all the time." Danny Vinyard -American History X
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.
I think a mistake you are making a mistake in understanding, the process isn't invisible or even hard to spot, but rather the resources being used are, a simple ps would still show the process.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.
Curiosity was framed, Ignorance killed the cat.
Some instances of IBM's VM.. (VM/HPO, VM/ESA and z/VM.. VM/370 and VM/SP had a more simplified version with only 2 queues).
--Ivan
Absolutely. In fact I think it should go half a step further. In the interest of civility, using this feature should hide the message from casual viewing. But a single click will still bring up the original so that you can't use slashdot to be a complete ass and then censor yourself after the damage is done :)
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.
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.
May contain traces of nut.
Made from the freshest electrons.