Arts < 1.0.2 local root exploit

[Andreas Pour]

Neil Stevens wrote:

[ ... ]

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

Right, and I think it is a reasonable choice, but, misses the point I am
trying to make :-).

BTW, how does esound deal with this issue? 
 
> And guess what?  Realtime is off by default, and packagers don't have to
> suid artswrapper.

I am more concerned about what the authors and/or KDE say about it. 
Looking at the docu
(http://www.arts-project.org/doc/manual/index-2.html), I think it could
be improved to highlight the tradeoff.  Looking also at the FAQ
(http://www.arts-project.org/doc/handbook/faq.html#id2803921), there is
a "supposed to be" comment.  Looking at the Makefile.am in
arts/sounddserver, there is a "please make
$(DESTDIR)$(bindir)/artswrapper suid root" comment.  There are probably
other places too where the subject is addressed.

In terms of it being off by default, I guess that depends:  if you "make
install" as root, it's not, see the afore-mentioned Makefile.am.  As to
what packagers do, they may actually follow the arts documentation
suggestions, hence my reference to that above.

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

I think you missed the point I was trying to make.  If you are decoding
in the application, you can run that at a higher priority to make sure
you can decode fast enough.  My question is, how do you make sure the X
Server has a high-enough priority to ensure it can display the video
fast enough, as of course it is in a different process?  If you do not
elevate X11's priority, it could very well be the decoding process has
the video to feed, but nobody to read it.  I'm not sure that elevating
the server's priority is in KDE's control, and even if so, it would not
prioritize the video clients' requests over other clients' requests.

I'm also curious about your last point.  If you cannot use a pipe (or, I
guess, socket), does that mean KDE will not support video for systems
with X servers that lack the shared memory or xvideo extensions? Or do
you just mean performance will suffer?

[ ... ]

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

Hmm, what planet is this coming from ;-) ?

> KDE supports kiosks with strange
> optional stuff, why can't single-user setups get support for realtime
> where desired?

Where did I suggest they should not be able to?
 
> 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.

I'm a user, and I worry about that - not that I'll do it "malicously",
but perhaps "inadvertently", or, perhaps it just happens to me, via a
bug in the program with elevated privileges.
 
> > 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.

Fair enough, now if only this were in the documentation, it would
actually be relevant :-).  Though providing some protection for others
does not seem a bad idea to me in any event.
 
[ ... ]

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

Possibly.  I haven't done a study to see where most home users'
preference is.  But since KDE does not provide binaries, that's not an
issue we need to determine.  What we can do, however, is provide the
information in the documentation that permits those building binaries to
make an informed choice.
 
[ ... ]

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

Why not?   But it also seems that in a multi-user situation one would
not want to elevate audio anyway, it really only makes sense when the
user is only hurting himself by playing audio.
 
> 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.

But if I understand this correctly, the resource limits no longer apply
when you run "realtime" (which, actually, makes sense, since if you
wanted restrictions, why run it realtime?  Doooh!).

Ciao,

Dre