107406 2003-07-09  20:45  /79 rader/  <andrewg@felinemenace.org>
Importerad: 2003-07-09  20:45  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <5491>
Ärende: TerminatorX local root
------------------------------------------------------------
Program: terminatorX 3.80
Impact: Users can gain local root
Discovered: jaguar
Writeup and exploits: Andrew Griffiths

1) Background

   'terminatorX is a realtime audio synthesizer that allows you to
   "scratch" on digitally sampled audio data (*.wav, *.au, *.ogg,
   *.mp3, etc.) the way hiphop-DJs scratch on vinyl records. It
   features multiple turntables, realtime effects (buit-in as well as
   LADSPA plugin effects), a sequencer and MIDI interface - all
   accessible through an easy-to-use gtk+ GUI.'
   - from the terminatorx.cx website.

2) Description

   terminatorX suffers from several potential local root exploits,
   due to a lack of input validation on the HOME and XLOCALEDIR
   enviroment vairables.

3) Notes

   The problems can be exploited by supplying a larger than expected
   enviromental variables.
   enviromental variables.

   The frequently asked questions[1] state that if you prefer
   performance, you should make terminatorX suid. The author goes on
   to state that,

   "Immediatley after the creation of the thread terminatorX drops root
    privileges before any files or devices are accessed. The problem is:
    the Linux pthreads manager thread cannot be told to drop it's root
    privileges, which means that while the two threads executing terminatorX
    code run with the real user's privileges, the pthread manager thread still
    runs with root-privileges. While I cannot see how a malicious user or
    software could utlize this thread to acquire root privileges it might
    still be possible, so you'll have to make your on decision on performance
    vs security."

    Depending on the library version of gtk+, the standard method of
    making terminatorX suid will not work. If it does, some tricks
    need to be employed.  To exploit this hole, there are various
    techniques you can use, which all come down to the fact there is
    no memory seperation between the root process and the user
    process. We decided the most elegant method of exploiting this
    would be to construct a shellcode which would overwrite the GOT
    entries, which in turn, traps all threads until we find the
    'interesting' thread.  the GOT entries, which in turn, traps all
    threads until we find the 'interesting' thread.

    The GOT entries would be overwritten with a value pointing behind the
    shellcode which was just run. This next section of shellcode has two duties,    detect if the thread it just caught was a priviliged thread, and depending
    on its status, either enter a loop, or continue on with the third part of
    the shellcode.

    The third part of the shellcode is a standard shellcode, ie,
    spawn a shell for us.

    To mitigate the risk, until a permenant fix becomes available,
    you can remove the suid status of the binary via chmod -s
    /path/to/terminatorX.

4) Detection
    To test if you are vulnerable, you can trigger the bugs via,

    HOME=`perl -e 'printf "x" x 8000'` /path/to/terminatorX
    XLOCALEDIR=`perl -e 'printf "x" x 8000'` /path/to/terminatorX

    if you get a Segmentation Violation, it is vulnerable. To test if
    it has any impact, check the suid bit.

5) Vendor status/notes/fixes/statements

   Both the author and mfurr@debian.org was contacted via email of
   the space of about 3 weeks, neither of which I recievd a response
   from.

References:
[1]     http://terminatorx.cx/faq
(107406) / <andrewg@felinemenace.org>/----(Ombruten)