Arts < 1.0.2 local root exploit

[Andreas Pour]

Neil Stevens wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday July 08, 2002 08:22, Andreas Pour wrote:
> > Cool!  Especially the (a) part.  I see the advantages of having higher
> > priorities to avoid gaps, but, putting everything into higher privileges
> > violates the rule of least privileges, or something like that.
> 
> But, on the other hand, every step of the process benefits from higher
> privilege: reading files from the disk, decoding, filtering, and making
> output to hardware.  I really don't think least privilege applies here.

Hi,

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.

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

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.

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?

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

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.

Just by example, sendmail monitors load, and when it gets over a certain
level, suspends its services.

> All this does is *increase* the amount of privilege needed to be grabbed,
> rather than diminish it!  Apps *and* the sound server would have to!

I am trying to make suggestions, will full awareness, that this will
take some discussion, analysis and thought to get right :-).
 
> 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?
 
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.

> > > Of course, we can't actually ditch aRts until at least KDE 4, for
> > > Binary Compatibility reasons.  So, some of us (well, me and whoever I
> > > bring aboard) will continue active development of aRts until then,
> > > even of others of us decide to stop.
> >
> > I'm not sure what you mean.  Is it not possible to split arts up and
> > maintain binary compatability?  At least theoretically, you can always
> > replace a function call, which arTs does internally, with an RPC, or a
> > socket, etc.  Can't the aRts interface remain exactly the same, but
> > split up the functionality into two programs?  Waiting until KDE 4 is a
> > long time . . . .
> 
> KDE 4 is a long time away, but what's the rush?

Not really a rush, I guess, as long as we eliminate any "recommendation"
to have artswrapper be SUID root.  In that case, the only rush is, to
try to get the system more responsive.

> 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.
 
> 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?
 
> > Well, I would be quite happy to listen in and throw in a bone where I
> > might contribute something, but as I do not know the aRts internals, I
> > would not feel cheated either if you thought the signal noise ratio
> > would improve without this participation.  Up to you.
> 
> Well, your comments on least privilege have led me to realize another
> argument against the arts split-up, that it would require the player apps
> themselves to grab realtime priority.  

Not really, since that would be the worst solution.  There are other
architectures to try to stay with the "least privileges" model.

But, turning back to the theme of the moment, since the risk of higher
priority is not really "permanent damage" (such as installing a trojan),
but rather a DOS (effective enough to completely disable the machine),
having a process monitor may acceptably solve the problem.

Please cc: me :-).

Ciao,

Dre