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."

Comments

Re:A Useful Tool

[cichlid]

"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

Talk about a fair share scheduler !

[ivan_w]

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

Re:What does this mean?

[SatanicPuppy]

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.

Re:What does this mean?

[SatanicPuppy]

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.