Teamspeak 3 RCE advisory by:
ff214370685e536b9ee021c7ff6b7680bfbe6008bc29f87511b6b90256043536
August 10, 2016


While auditing the Teamspeak 3 server I've discovered several 0-day
vulnerabilities which I'll describe in detail in this advisory. They exist in
the newest version of the server, version 3.0.13.

I found 10 vulnerabilities. Some of these are critical and allow remote code
execution. For the average user, that means that these vulnerabilities can be
exploited by a malicious attacker in order to take over any Teamspeak server,
not only becoming serveradmin, but getting a shell on the affected machine.

Here's the output of an exploit which uses two of the vulnerabilities:

  $ python exploit_teamspeak.py
  leaking distinct stack pointers
   '\xa2'  '\x9a'  '\x8a' . '_' .. '\xa0' 
  got a ptr: 0x7fa29a8a5fa0
   '\xa2'  '\x9a'  '\x9a'  'o' ... '\xa0' 
  got a ptr: 0x7fa29a9a6fa0
   '\xa2'  '\x9a'  '\xaa' . '\x7f'  '\xa0' 
  got a ptr: 0x7fa29aaa7fa0
  stack ptr: 0x7fa29a8a5fa0
  assumed stack base: 0x7fa29a5a5000
  sleeping a bit to avoid flood detection.......
  initializing stack sprayers............
  spraying the stacks............
  doing some magic.....

  Got a shell from ('127.0.0.1', 38416)
  ts3@ts3:/home/ts3/teamspeak3-server$ 


I won't release the exploit anytime soon, but I will note that writing one is
a great learning experience.


Next I'll describe my findings. I'll be referring to function names. The
Teamspeak developers strip their binaries of symbols, but they messed up once
and forgot to do so. 

If you want to follow along at home, I'm sure your favorite search engine can
help you find the non-stripped server binary.

Now on to the vulns!


--- vuln 1: race condition leading to use-after-free ---

The ts3 server is threaded. When accessing objects like a Client or a Channel,
which can be shared among threads, it's necessary to hold a mutex. However the
function VirtualServerBase::sendCommandLowPacket drops its mutex before
accessing a Client object. Here's the vulnerable code:

  0x49d26d:
  call    _pthread_mutex_unlock
  mov     rdi, client 

  ; this will mov rax, [rdi+0F0h]
  call    Client::getTransmissionReceiveBase(void) 

  mov     rcx, [rax]
  mov     rdx, [rbx+VirtualServer.vsb.vserv_id]
  mov     rdi, rax
  mov     rsi, r14
  call    qword ptr [rcx+58h]

As we can see, the mutex is unlocked and then a TransmissionReceiveBase struct
is taken out of the Client. Then its vtable is used for a call. Looking at
the kernel source we see that, at least on Linux, _pthread_mutex_unlock will
swap out the current thread if there's another thread blocked waiting for the
mutex.

This other thread could then free the Client and place controlled data on top
of the freed block. When the first thread runs again, we control the
TransmissionReceiveBase object completely. The indirect call through its
vtable allows us to get $pc.

This is one of the vulnerabilities used in the exploit above.


--- vuln 2: disclosure of a partially uninitialized stack buffer ---

When a client first connects to the server, it sends over an IV. The IV is
base64-encoded. The server decodes it in VirtualServerBase::clientInitIV.
However the server ignores the return value of Crypt::decodeBase64 which is
the decoded length. Instead it assumes that the length is always 10 bytes.

If the client only encodes e.g. 9 bytes and sends them over, one byte of the
IV will be uninitialized. The client can guess this byte. Only a correct guess
will prevent later cryptographic operations from failing. Thus the client can
deduce the byte. It can repeat the process, sending over only 8 bytes, etc.
This lets us do a byte-at-a-time leak from the stack. 

Specifically it lets us leak a stack pointer, beating ASLR. This was used in
the exploit above.


--- vuln 3: disclosure of heap memory ---

The ts3 server compresses command packets with the "qlz" library. However a
known vulnerability resides in one of the older versions of this library.
This was already fixed in the newest qlz release (a beta release). However the
ts3 server uses an older version of this library.

The vulnerability is described here:

  https://blog.frama-c.com/index.php?post/2011/04/05/QuickLZ-1

But it's straightforward to find for anyone looking at qlz's source code. You
don't need any fancy "software analyzer" to find it, like in that silly blog
post.

The vulnerability is qlz-specific and essentially allows you to "decompress"
data, but much of the decompressed data is actually uninitialized. 

Why is this a problem for the ts3 server? Because we can send a short
compressed command packet over which starts with "some_command return_code=".
When we use this vuln and the packet is decompressed, the following bytes will
be included in the packet. So the packet that ts3 sees is "some_command
return_code=<bytes from the heap>". 

Since the return_code parameter is reflected back to us, this lets us leak
data from the heap.


-----

Those three vulnerabilities were the critical ones. Below I'll briefly
describe some minor ones, resulting in DoS or more interesting things.




--- vuln 4: check if any file exists on the server ---

The function VirtualServer::getpermission_fileTransferInitDownload accepts a
path from the client and gives different error messages depending on whether
the file exists or not.

For example using "/../../../etc/passwd" gives "bad path" while
"/../../../etc/passwz" gives "no such file". This can be used to determine the
remote OS and installed software, enumerate open fds, etc.


--- vulns 5, 6, 7, 8: race conditions galore ---

The function PermissionManager::getChannelGroupInherited looks up and uses a
Channel struct without holding any mutex. The channel is only used to look up
a channelid, so this is an infoleak/DoS at best.

In the function VirtualServer::sendRemoteDebuggingInfo we look up a Client
struct, then drop the mutex, and then we proceed to use the Client to look up
its uuid. Again this is an infoleak/DoS at best.

In ServerParser::cmd_permget we look up a Client without holding any mutex.

In ServerParser::cmd_clientsetserverquerylogin we do the same.


--- vuln 9: ParameterParser index-out-of-bounds DoS ---

In PacketHandler::inINITPacket_SolvePuzzle we initialize a ParameterParser. It
keeps a vector of parameters. Later, in ServerParser::inPacket, we call
ParameterParser::getParam to get the parameter at index 0. However it's
possible to send just the string " " which will result in the ParameterParser
vector having zero entries. Then this zero-indexing will go out of bounds. 

This is unfortunately a DoS at best since the retrieved parameter is just
compared against "clientinitiv", which isn't terribly useful.


--- vuln 10: double clientinit DoS ---

If we run the "clientinit" command twice, the server crashes with a failed
assertion.





Q&A:

Q: What can normal users do?
A: Wait for the Teamspeak developers to patch the vulnerabilities, then download
   a new version of the server. Exploiting these vulns to get RCE is quite
   tricky and it's unlikely that anyone will manage to create a working
   exploit before a patch is released.

Q: How did you find these?
A: Lots of staring at disassembly.

Q: Why not do coordinated disclosure?
A: The Teamspeak developers censor their forums and sweep vulnerabilities
   under the rug as "crashes". I am not comfortable with that. Furthermore I
   fear legal action from them.

Q: Does this mean that Teamspeak is totally insecure? Should users move to
   other VoIP software?
A: Any complex piece of software has vulnerabilities. I would guess that
   similar things could be found in Mumble/Ventrilo/etc., if enough time were
   devoted to it.
   


Advisory by:
ff214370685e536b9ee021c7ff6b7680bfbe6008bc29f87511b6b90256043536