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)
