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 mfurrat_private 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
This archive was generated by hypermail 2b30 : Wed Jul 09 2003 - 11:48:04 PDT