Arts < 1.0.2 local root exploit

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday July 09, 2002 11:32, Andreas Pour wrote:
> Is there a KDE system that applies higher privileges to disk
> scheduling?  At least Linux does not, AFAIK, I think it applies only to
> CPU scheduling.

It's all the same in principle, though.  If better disk scheduling is made 
available, we'll surely need root to grab it.

> The output to hardware would, under a split, of course still be
> realtime, so I think what's left is decoding and filtering.

Yes.

> Now, the way I understand this process, it requires calling large,
> complex libraries provided by third parties, such as libogg or libmp3,
> and so, there is no way to do effective security auditing.  For this
> reason, I, for one, would not want to run this software at a higher
> priority, and I do not think, that KDE should recommend anyone else to
> do the same either (which is what we effectively did, up until a few
> days ago).  Making the option available, with a suitable warning, is of
> course fine, perhaps supplemented by a method for specifying which
> decoders are sufficiently "trusted" for this privilege, so that a user
> may choose to have some mature, well-tested libraries run at higher
> priority, while having other processes run at a lower priority.

Well, I don't want a skip every 10 seconds during heavy compiles, so I 
absolutely do want it run with realtime.  The unaudited code isn't running 
with root, so my data isn't at risk, just my CPU.

And guess what?  Realtime is off by default, and packagers don't have to 
suid artswrapper.

> Perhaps another perspective to consider, since kdemultimedia is
> expanding its video framework, is how video, which requires far greater
> resources for decoding and pumping to hardware, will be made a higher
> priority?  How do you have one processes' X window have a higher
> priority, exactly?

Video works only because it can use hardware services via XVideo or things 
like that.  Let's note further that video can only be done on *one* side.. 
you can't send video data across a pipe and expect to be fast enough.  So 
in the split case, you end up with the app side having to do video 
hardware output.

> > Ooh, and I just realized: by moving decoding into the application,
> > rather than leaving it on the server, that means that KDE apps would
> > get to have the fun task of gaining root, grabbing realtime, and
> > dropping root again.
>
> Sure, if you want to have decoding be "realtime" and under the app's
> control.  OTOH, to add some measure of security, the core part could
> optionally provide this service, based on a configuration file.

So you simply don't care about single-user setups, and won't give them 
optional settings to benefit from?  KDE supports kiosks with strange 
optional stuff, why can't single-user setups get support for realtime 
where desired?

Security may not be optional, but for every situation there are different 
threat models.  On the typical home workstation, a user isn't worried that 
he'll maliciously DoS himself.

> And, this has me thinking, since the biggest risk of a high priority is
> a very effective DOS, it may be possible to have an architecture where
> the processes with a higher priority are monitored, and, if the CPU
> usage exceeds a certain threshold - say the load goes above 15 (or some
> configurable threshold) - that this process is put to sleep (the
> "monitor" process could be quite compact, and would of course need a
> higher priority, by say 1, than the decoding processes, so that it will
> be sure to receive CPU time to perform its monitoring function) and the
> user presented a dialog to restart it.
>
> This, at least, would be a way to limit trivial exploits that lock the
> system so hard you cannot even get console access to kill the offending
> process.

Sure, but in our situation, it's not necessary.  On systems that are 
worried about a DoS, realtime should be disabled by removing the suid bit 
from artswrapper.

> > Audio playback is a hard real-time task.  If you don't meet the
> > deadline, the user's ear suffers.  So don't try to tell me decoding
> > shouldn't have to run realtime.  I want to be able to use noatun while
> > doing two enable-final compiles.
>
> The case seems worse to me for video.  How do you plan to address that
> issue?

With the same thing we have now?  Why not?

> And as far as your personal situation is concerned, I am not suggesting
> that some mechanism be put in place to *prevent* running in real-time, I
> am merely addressing the "KDE as shipped" issue, which, IMHO, should be
> as secure as reasonably possible, but in any case should not have the
> trivial exploit currently available against aRts (when using the suid
> wrapper) to bring down multi-user systems.

Then you have to answer, definitively, what one set of users KDE ships for.  
Does KDE ship for the big companies with mass multi-user installs, or does 
KDE ship for millions of home single-user setups?  In this case, the 
optimization for each is contradictory.

The security is fixed by removing one bit on the artswrapper install.  The 
skips in playback are fixed by adding that one bit.

> > I'm seeing a lot of people
> > claim that Noatun works better than ever for them in KDE 3.  KDE 3.1
> > will see xine_playbobject and support in Kaboodle and Noatun.  Now
> > seems the *worst* time to be throwing it all away with a rewrite.
>
> I don't see how splitting things up affects arts clients.

The point is "If it isn't broke, don't fix it."  Once you remove the 
default suid bit from artswrapper, it's not broken.

> > As for rewriting it in place with binary compatibility, if it can be
> > done I guess it can be done.  It'd just have to prove itself a worthy
> > replacement: not losing any functionality, maintaining skip-less
> > performance for those who get it, and not wasting resources.
>
> I am leaning more toward thinking the idea of having a monitor which
> detects DOS attacks via prioritized proceses as being perhaps the best
> interim solution?

I really don't think that's needed.  I don't expect multi-user boxes to 
actually use audio to begin with. :-)

But, in the end, resource limiting should already be in place on any system 
with untrusted users, so it probably is the answer to go with, combined 
with the recommendation to -s artswrapper when you don't trust your users.

- -- 
Neil Stevens - neil at qualityassistant.com
"I always cheer up immensely if an attack is particularly wounding
because I think, well, if they attack one personally, it means they
have not a single political argument left." - Margaret Thatcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9K6Thf7mnligQOmERAuOXAJ94R167GzfFVQ8DLUJ6OVwpUKzb+QCeM5K/
uTzkKYw8fl7k7EmVpEmgBfY=
=+tyF
-----END PGP SIGNATURE-----