artswrapper defanged

[Stefan Westerfeld]

   Hi!

On Fri, Jul 19, 2002 at 08:51:23AM +0100, Rik Hemsley wrote:
> > What you _should_ have done is publish a security advice that tells
> > people to remove the suid bit of artswrapper. This has the same
> > effect as patching the feature away in the source: None. But it would
> > have saved people a lot of breath.
> 
> There is already a security advisory, in fact, that's where I heard
> about the exploit.
> 
> I have not heard that artswrapper has been fixed properly yet. We're
> approaching another release. If I hadn't patched artswrapper, would the
> next release have gone out with the exploit still open ?

Well, you don't seem to understand the nature of the "exploit".

The _very purpose_ of artswrapper is to give artsd a very high priority and
drop the root privileges thereafter. It does _exactly_ this. So artswrapper
is neither broken nor vulnerable.

The _very purpose_ of a sound server is to compute the things (sound, that
is), that the user wants to compute. This produces CPU usage, and depending
on how complex the computations are, more CPU usage.

The _combination_ of these two purposes leads to a straightforward "local
denial of service attack": you let artsd compute lots of things. Since artsd
monitors its own CPU usage, you can only safely take away 90% of the CPU usage
a system has. Solution: start another artsd. Then you can take away 100% of
the CPU usage a system has. So a non root user can produce a system hang in
tiny shell script (will not post it here).

And this exploit does not include loading plugins with user supplied code
into artsd, in which case you can patch away the self monitoring and then
enter into a for(;;); loop.

Thus, there is no "fixable hole" in the usual sense. Either you throw away
some things that are considered useful features, or artsd will be abusable by
local users to bring your machine down. Note that this already requires you
to start programs as local user (i.e. shell access), there is no "remote
denial of service exploit" artsd is known to be vulnerable against.


You might also give up the concept of server side computation to "fix the
problem", but that means giving up a fundamental design decision in aRts, which
in turn means a redesign/rewrite. Which means rewriting _a lot_ of code
(basically 100000+ LOC). Nothing that could not be done, nothing that I have
not thought about, but nothing you do in a minor release (KDE3.1), but if at
all in a major release (KDE4).

So I don't see how "the problem" could be straightforwardly "fixed".


There is another chain of argumentation which says: if it is potentially
dangerous, it should not be the default. I think what /could/ be done is to
get rid of a suid artswrapper in the default install. Instead, if a user
chooses realtime in kcontrol, ask him for the root password if artswrapper is
not SUID root yet, and make it SUID root, then.

This fix would be not too user friendly, in the end, as lots of users would
be bothered with thinking about the details of what realtime priority is, and
how it works, or, if they don't think about it, would have broken and scratchy
sound. Contrary to popular belief, starting artsd realtime is default right
now, so that in fact no user right now needs to even think about what a sound
server is to get dropout free sound. It works great by default because it
always gets realtime rights.

But well, if consensus is that security is more important in sane defaults
than usability or user friendliness, then I think that making this step a
lot more explicit would be the only way to go. It will lead to bug reports
"can't get my sound right" and to frustrated users who don't write bug reports,
and never find the problem, but if security against local denial of service
attacks is the topmost goal, then thats the way to go.

Note that I think this is overreacting. You can bring down almost any system
with a

   for(;;) { malloc(4096); fork(); }

program. Why bother if artswrapper can be used to achieve the same, then?

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