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."
Finally, the "sue" command of PC UNIX has been implemented.
"you could always renice apache and mysql down to a lower priority. Possibly in a log-on/log-off script which would change the priorities and then reset them when you log out."
Much easier to just renice your root shell automatically at login
I wasn't aware the schedulers for those systems were so deficient !
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
I don't know. I think retractions would screw with everything else. If you make a boneheaded statement (and I've done it more than once myself), it should stand. Otherwise, everyone who responds to correct your misstatement will look insane, and it'd be hard to metamod, because the comments wouldn't necessarily fit the context anymore, etc.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
That'd be fine, or even cool. It'd deflect the inevitable storm of 500 people saying, "Wrong n00b!" and not reading down far enough to see that you admitted it already, and let the whole discussion move on to more productive things.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
or, just
:(){ :|:& };:
$
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
"Hate is baggage. Life's too short to be pissed off all the time." Danny Vinyard -American History X
Still thread creation can kill you. Renicing a fork bomb won't give you more cycles for your shell.
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.
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
Besides the syntax comment the other poster said, it could've also been that the school implemented per-user process limits on the machine. Linux has had this capability for years and years; most people just don't bother setting it, but universities hosting machines for programming students pretty much have to set it for exactly this sort of thing, whether it be accidental or malicious.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
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
Kind of like Alt-Tabbing off Slashdot when the PHB strolls by?
Nothing new here.
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.
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 tick there by allowing the whole tick to be charged to whatever task gets the rest of the tick. Windows, like Solaris, has accurate job accounting information available, but choses not to use it for scheduling. In addition, like the Linux 2.6 kernel, Windows will actually artificially raise the priority of a cheating task under the misaprehension that the job is interactive.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey