TeamSpeak - Weird hard coded directory, Buffer Overflows etc...

[Derp]

Ok...

Today I was checking a process using ProcMon and I thought about using it to see what teamspeak was accessing.

Interesting stuff I found

Spoiler: Buffer Overflows

Spoiler: Weird hard coded directory

ts3client_win32.exe 2868 QueryOpen C:\jenkins\workspace\Dependencies-Qt-Windows\5.4.1-32\qtbase\plugins PATH NOT FOUND

Spoiler

ts3client_win32.exe 3748 RegOpenKey HKLM\Software\Microsoft\Cryptography\DESHashSessionKeyBackward NAME NOT FOUND Desired Access: Read
ts3client_win32.exe 3748 RegOpenKey HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Cryptographic Provider v1.0 SUCCESS

-Derp

 

[ehthe]

That hard-coded directory is where the app was built. There are a lot of them and they can be very useful when learning how things work
The buffer overflow thingy seems interesting. Could you expand the path as to see the precise file that causes it ?

 

[Derp]

That hard-coded directory is where the app was built. There are a lot of them and they can be very useful when learning how things work
The buffer overflow thingy seems interesting. Could you expand the path as to see the precise file that causes it ?

Actually from ProcMon's output I noticed that It only happened when QueryAllInformationFile was called.

The exact path is

Spoiler

ts3client_win32.exe 2528 QueryAllInformationFile C:\Documents and Settings\Private\Application Data\TS3Client\chats\K1ZPQzNvSkVkNWY5RERrbUxrREZha1dGSGpNPQ==\channel.html BUFFER OVERFLOW

Interesting:

AllocationSize: 475,136,
EndOfFile: 469,249,

NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x7400000000bbe9, EaSize: 0, Access: Generic Write, Read Attributes, Position: 469,249, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Word

Basically, this happens when It tries to get data from channel.html

 

[ehthe]

Does it happen with the txt counterpart ?

 

[Derp]

Does it happen with the txt counterpart ?

Yes

 

[ehthe]

Did a quick search. It seems that this error is a return code when the buffer provided by the program is too small. So no exploitation possible from that point it seems.

http://www.howtogeek.com/school/sysinternals-pro/lesson4/all/?PageSpeed=noscript
https://superuser.com/questions/491597/process-monitor-entrys-with-buffer-overflow

 

[Derp]

Did a quick search. It seems that this error is a return code when the buffer provided by the program is too small. So no exploitation possible from that point it seems.

http://www.howtogeek.com/school/sysinternals-pro/lesson4/all/?PageSpeed=noscript
https://superuser.com/questions/491597/process-monitor-entrys-with-buffer-overflow

It actually seemed very unbelievable, BUT, I don't think ALL of them were false positives.

I remember checking one of the Buffer Overflow errors (It had nothing to do with the TS Cache) and I noticed something like this

AllocationSize: 269
EndOfFile: 399

I'll see if I can reproduce that,

I'll let you know

 

[ehthe]

The thing is if you see an error in procmon it means that it is returned by the windows API. In short it is handled by windows and returned to teamspeak as an error.
(I may be wrong as it has been ages since I last used it)

 

[Derp]

I think it's worth giving it a try, we have nothing to lose anyway

 

[ehthe]

Indeed

 

[Derp]

Ok.
Looks like I can't reproduce the overflow I noticed before... The best I could find was AllocationSize matching the exact size of the file.

:/