aRts < 1.0.3 local root exploit

Stefan Westerfeld stefan at space.twc.de
Tue Jul 9 14:46:18 BST 2002


   Hi!

On Mon, Jul 08, 2002 at 02:16:59PM +0200, Dirk Mueller wrote:
> It seems the posting on bugtraq was a fake, there is no exploitable local 
> root. However, there are plenty possibilities of local DoS attacks when 
> realtime scheduling is allowed and enabled. 
> 
> [...]
> 
> Will we enhance security of arts for KDE 3.0.3 / 3.1 ?
> 
> things like: 
> - refuse to run as root, setuid to nobody then or similiar

I don't see the point here. If you are running as root, only the plugins from
the standard installation and those specified in ~/.mcoprc will be loaded, so
that no local user can do anything harmful. In the standard setup artsd is
also only listening on /tmp/mcop-root which is not user-readable/writeable.

I see no potential for exploits here. There is cookie authentication even
if you run on a TCP port. Of course, if disable this (artsd -p 1234 -u)
you will have an unlimited security hole, but -u is mentioned as dangerous
in the documentation and not available as checkbox or something like this
in the gui, so you need to explicitely ask for shooting yourself in the foot.

> - refuse to load player plugins from nonroot, different users

I don't see that as a goal either. You need to load player plugins if you're
developing new stuff, and maybe you also want to install aRts dependant
applications (like Rosegarden) locally even if you are not root. Those apps
come with their own plugins.

> - fix the exploitable buffer overflows in arts

Sure, if somebody finds exploits due to unclean coding, they should be fixed.
There are no known "useful" exploits at this point in time, though. You can
only crash your own private local artsd yourself, nobody else can.

> Should we recommend to disable realtime priority (i.e. remove the suid bit 
> on artswrapper)?

For systems that are heavily multi-user, yes. For instance, I would recommend
it on large university installations and things like that, because you might
not want to have local DoS attacks there. For systems that are mainly single-
user, like your local PC at home, there is no reason to disable it. In the
contrary, it is required to have it enabled to get useful audio quality and
latencies.

> Should we make the non-suid artswrapper the default ?

I think not. Most installations are single user, and for those that are multi
user, there is no critical risk (i.e. you can't gain root rights, you can't
read other peoples files, ...). However, adminstrators of those systems might
want to remove the suid bit. Distributions which have more than one security
level (such as SuSEs easy ... paranoid) might want to disable the suid bit in
higher security levels.

Always disabling it will only lead to complaints by "normal" users which want
to listen to their mp3 files while doing other things. They will usually not
have the required skills to know how to reenable it.

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



More information about the kde-multimedia mailing list