Bugzilla Bug 26781

TerminatorX local root 
 
From:  
andrewg@felinemenace.org 
 
 
To:  
bugtraq@securityfocus.com 
 
 
Date:  
2003-07-09 13.29 
 
 
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

*** Bug 26709 has been marked as a duplicate of this bug. ***

*** Bug 27656 has been marked as a duplicate of this bug. ***

terminatorx 3.81 is now in portage. I'm not going to close this as i guess
someone in security will want to review.

Thanks for taking care of this bug J. Ellis

A GLSA needs be sent out about this one.

changing resolution to FIXED (not sending any GLSA's)