artswrapper defanged

[Stefan Westerfeld]

   Hi!

On Fri, Jul 12, 2002 at 12:27:02AM +0100, Rik Hemsley wrote:
> I have modified arts/soundserver/Makefile.am to stop it installing
> artswrapper suid and also stop asking the user to do so themselves
> if it fails.
> 
> I have also modified artswrapper.c to stop trying to raise its own
> priority, in case someone does make the binary suid.
> 
> I made these changes as a temporary measure until the denial
> of service vulnerability is fixed.

First of all, I would expect anybody committing significant changes to aRts
to either ask before committing, or know exactly what you are doing. I think
thats a matter of working together and not against each other.

Second, for the reasoning of why artswrapper exists: you can not guarantee
dropout-free sound at low latencies with the standard linux timesharing
scheduler. Some applications however, such as quake or Brahms need low
latencies to be useful. The effective latency is the amount of buffering
performed in both, the application and the sound server. Now if you want
the sound server to be "non intrusive" in terms of "adding little or no
latency", you need to keep the sound server buffers small. This on the other
hand increases the risk of dropouts under standard timesharing scheduling,
which is why a raised priority makes sense.

Ok, so suppose it makes sense. Is it dangerous? Yes of course. A

	for(;;);

loop can hang your system. What can we do against it? We can check our own
CPU usage periodically, to avoid system hangs. Artsd does this since forever,
which is why it never caused system hangs for me during development after the
introduction of the self-CPU-usage-monitoring.

Next point: is it abusable? Depends. There are, as Neil pointed out, two cases:
we trust users, or we don't. If we don't, its abusable. Why?

Because
 (1) you can make artsd do arbitarily complex calculations (i.e. decode more
     than one mp3 at once, start a complex synthesis network server side,
	 configure the sampling rate to a high number, such as 1 Mhz)
 (2) you can load arbitary code into artsd, via the plugin mechanism
 (3) there might be problems with the code, such as the one just discovered,
     which allow you to execute arbitary code inside artsd

Now, could you abuse this? Certainly. I don't want to post detailed recipes
here, but basically, there are a lot of ways to either trick or kill the self
monitoring and then do your for(;;); loop. Voila. DoS.

Can this be "fixed" within artsd? No. You might possibly fix (3). However,
you can't remove (2) without removing significant functionality (namely, the
ability to have a modular sound server, rather than a monolithic). And even
if you do this, still (1) remains. So, with the current artsd and the current
design, you have lost in the moment where you have an abusive user.

Can this be "detected and avoided" by an external monitoring process or by
a kernel extension?

Certainly, this could be done by a kernel extension (or a new scheduling policy)
which I would consider the most reasonable solution, given that artsd might
not be the only RT application, and given that the scenario "you want that
RT applications perform nicely, but never tear down your system" is not that
uncommon.

I think such attacks are also detectable by an external watchdog process,
which has the following properties:

(a) it runs at higher priority than artswrapper
(b) it _never_ terminates
(c) it can't be terminated by anybody (but root)
(d) it controls whether an application can aquire realtime rights or not
(e) it spawns a low priority process and watches whether this process gets
    CPU time or not
(f) it depriorizes all other realtime processes IFF the low priority process
    is dead for a while, and disallows acquiring realtime rights for a certain
	amount of time (60 seconds or so)

These properties might make it possible to defend a system even against
malicious users trying to abuse realtime priorized applications. Note that
the user could still cause significant pauses, but the system would remain
"life" in the long run. But, it seems that such a watchdog would be

 - somewhat non-portable
 - quite ugly (because you can't kill it as user - if you could, you could
   kill it and then do your DoS attack)
 - something that exceeds the scope of aRts
 - something that might affect other processes that were not started by
   artswrapper


So, basically, I think what you demand ("fix holes before we can reenable
this") is impracticable. We don't want a kernel extension, and the user
space watchdog seems to be kludgy.

IMHO the most reasonable way to go is to not change anything. Users can
disable realtime if they feel like it in kcontrol. Root can disable realtime
if it feels like it by removing the suid bit. Packages can disable realtime
if they feel like it by packaging without suid bit. (And SuSE for instance
does this, depending on the security level [easy..paranoid). Endusers benefit
from realtime. It has worked for ages like it was. Why change it?

Writing the external unkillable watchdog will add an extremely ugly piece of
code. I don't think users will be happy to see "artsguard" running even after
they logged out of KDE (but it has to, for if you could terminate it,...).

So I think you should revert your commits, and instead propose changes to
the documentation/FAQ/Makefile, if the risks are underrepresented there.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-