[Full-Disclosure] TerminatorX local root

• Previous message: andrewg_at_felinemenace.org: "[Full-Disclosure] Coda RPC2 Denial of service"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: full-disclosure@lists.netsys.com
Date: Wed, 9 Jul 2003 04:29:57 -0700

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.

   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 would be overwritten with a value pointing behind the

    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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Previous message: andrewg_at_felinemenace.org: "[Full-Disclosure] Coda RPC2 Denial of service"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]