[VulnWatch] Re: LOCAL ROOT EXPLOIT - SUPPORT FULL-DISCLOSURE - LOCAL ROOT EXPLOIT

From: Olaf Kirch (okir@suse.de)
Date: 07/08/02


Date: Mon, 8 Jul 2002 13:03:04 +0200
From: Olaf Kirch <okir@suse.de>
To: kanix THE HACKER <kanix@twinkie.com>


Disclaimer - I investigated this issue on SuSE, not RedHat, so
the situation there may be somewhat different.

On Sun, Jul 07, 2002 at 09:43:06PM +0000, kanix THE HACKER wrote:
> This is a local exploit for a format string vulnerability in
> /usr/bin/artswrapper on Red Hat Linux release 7.2 (Enigma).

Hm. I am not quite sure why this exploit should give you a root shell
(unless RedHat made artsd setuid root, too).

artswrapper does a seteuid(getuid()) which sets the effective uid back
to that of the caller. Then it calls execv(/opt/.../artsd). The execv
call takes care of the saved uid. So what you get is a shell running
with realtime scheduling priority, but no root privilege.

For what it's worth, there are simpler methods to obtain a process with
RT-privilege using artsd. Compile the attached program as /tmp/lalla
and check:

        $ artswrapper -m /tmp/lalla -a foo
>> running as realtime process now (priority 50)
        Current scheduling policy is FIFO

Which is disturbing, but a far cry from root privileges as claimed
in the original posting.

Apart from that, artsd has a load of other ways to break it. Unchecked
vsprintf calls in arts/mcop/debug.cc for instance. But given that
artsd is linked against 16 shared libraries I'm sure there are
at least that many different ways to exploit it.

Fortunately, KDE seems to have picked up the habit of protecting the
directory in which the mcop communication socket resides so that
no-one except the user running artsd can connect.

If I am not mistaken, the original intention of giving artsd real-
time scheduling policy was to make sure that sound data was being
fed to the sound device with a low latency; which is important for
many sound cards which have ridiculously small buffers. It seems
though that artsd has mutated into something much bigger in the
meantime; maybe it's time to consider whether one shouldn't split
off the part feeding the audio device...

Olaf

-- 
Olaf Kirch     |  Anyone who has had to work with X.509 has probably
okir@suse.de   |  experienced what can best be described as
---------------+  ISO water torture. -- Peter Gutmann




Relevant Pages

  • Re: LOCAL ROOT EXPLOIT - SUPPORT FULL-DISCLOSURE - LOCAL ROOT EXPLOIT
    ... Disclaimer - I investigated this issue on SuSE, not RedHat, so ... with realtime scheduling priority, but no root privilege. ... RT-privilege using artsd. ... time scheduling policy was to make sure that sound data was being ...
    (Bugtraq)
  • Re: Sound driver latency
    ... > Artsd... ... I am not using KDE, and just tried Artsd with OSS, running it manually from ... then set my xmms preference to use arts sound driver. ... My sound card is Creative Sound Blaster AWE ...
    (RedHat)
  • Re: Cant access soundcard by several application at the same time.
    ... > multiple programs accessing the same sound device simultaniously. ... That should work fine if you run artsd or alike and all apps are ... Artsd supports nas (network audio system) in addition, ... Michael Heiming ...
    (alt.os.linux)
  • Fwd: Re: [SLE] Disable ARTS
    ... And you know what -- suddenly my regular sound has a much higher volume (I ... My intuition is that arts is has been a huge problem for audio in Suse since ... But if the artsd system ... > Microsoft Windows Free Zone - Linux for all Computing Tasks ...
    (SuSE)
  • Re: [SLE] artsmessage : Sound server fatal error, cpu overload
    ... > selected ALSA as the sound system in KDE Sound Config rather than Auto ... > I am not sure which is the culprit ALSA or artsd. ...
    (SuSE)