Arts < 1.0.2 local root exploit

Stefan Westerfeld stefan at space.twc.de
Tue Jul 9 22:45:21 BST 2002


   Hi!

On Tue, Jul 09, 2002 at 01:32:20PM -0500, Andreas Pour wrote:
> 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 don't see the gain, as artsd already monitors itself for CPU usage. So
/bugs/ in code shouldn't bring artsd down, as it kills itself with the comment
"CPU overload" if its own CPU usage is very high for a while. Of course you
can argue that a "real" exploit would possibly be able to find a way around
artsds self monitoring (I will outline a complex exploit below).

So you might say an external daemon is safer, and if you feel like writing
one, please go ahead. Make sure that the user has no influence on stopping
or affecting the monitor process in any way, because if the user has, he can
stop/kill the monitoring process before beginning his DOS exploit.

You also may want to handle the case where the user starts and stops artsd
and/or child processes repeatedly to hide the CPU usage in multiple sub-
processes. Or even logs himself in several times with several accounts to
spawn the DOS attack over multiple accounts.

So I think if you want to write a perfect protection against this, it can't
be provided (and started) by KDE itself, but needs to be something like an
always running system service (or kernel service) monitoring all realtime
processes all the time for potentially destructive behaviour.

However, as long as I can DOS most systems with malloc/fork combinations
(linux goes into OOM killing after a while), I don't see the point.

   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