not a 0day in general, but it may be for ts3 :)

Supervisor

Supervisor

Administrator
Apr 27, 2015
1,863
2,546
335
TS3 Client - lower than QT Version 5.4.2 (current: 5.2.1)

DoS Exec Code Overflow 2015-05-12 2015-05-13
Multiple buffer overflows in the QtBase module in Qt before 4.8.7 and 5.x before 5.4.2 allow remote attackers to cause a denial of service and possibly execute arbitrary code via a crafted GIF image.

DoS Exec Code Overflow 2015-05-12 2015-05-13
Multiple buffer overflows in the QtBase module in Qt before 4.8.7 and 5.x before 5.4.2 allow remote attackers to cause a denial of service and possibly execute arbitrary code via a crafted ICO image.

DoS Exec Code Overflow 2015-05-12 2015-05-13
Multiple buffer overflows in the QtBase module in Qt before 4.8.7 and 5.x before 5.4.2 allow remote attackers to cause a denial of service and possibly execute arbitrary code via a crafted BMP image.

DoS 2014-05-08 2015-03-26
The GIF decoder in QtGui in Qt before 5.3 allows remote attackers to cause a denial of service (NULL pointer dereference) via invalid width and height values in a GIF image.

Source: www.cvedetails.com/vulnerability-list/vendor_id-12593/product_id-24410/version_id-164958/Digia-QT-5.2.1.html


So basically, that tells us we can put php code into .gif
So if I do understand this - we could easily gain access to the shell user executing the ts3server. If the server is not setup properly.. you may even get access to root o_O

http://php.webtutor.pl/wp-content/uploads/2011/04/php-logo-virus.jpg
this image does contain php code, too bad I don't know how to do that with .gif

->> rm -rf /* haha
 
Last edited:
ehthe

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,028
896
216
The server doesn't use QT at all ! But the client does so you could hijack clients :D
 
Asphyxia

Asphyxia

Owner
Administrator
Apr 25, 2015
1,844
2
2,197
327
I'm not positive which version of QT TeamSpeak 3 uses, however because both Mumble and TeamSpeak 3 use the QT Framework, it may be beneficial for us to investigate whether these mentioned QT security issues may be abused in both Mumble and TeamSpeak 3. :D
 
Supervisor

Supervisor

Administrator
Apr 27, 2015
1,863
2,546
335
When we'd get code to work accepted in the shell. . It would be the biggest security breach in history of both clients
 
Supervisor

Supervisor

Administrator
Apr 27, 2015
1,863
2,546
335
TeamSpeak currently uses 5.2.1 however the bug occurs till 5.4.1... they might have done a external check in gifs though if they knew about it. .
 
ehthe

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,028
896
216
Testing with https://bug255067.bugzilla.mozilla.org/attachment.cgi?id=156329

No error on the banner but it doesn't show anything (you have to bypass the server telling you that https is incorrect by directly editing the db).
On a channel it detects that it is too large.

But the fact that the server refuses to let you enter a https link is very much interesting :D
 
ehthe

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,028
896
216
Alright managed to crash the client with that last one :D
(Started a thread)
 
Last edited:
Supervisor

Supervisor

Administrator
Apr 27, 2015
1,863
2,546
335
ehthe said:
Does not seem to be exploitable with teamspeak (additional check on the size). Still we need to be sure :)
Click to expand...
Is that for all the bugs or just for the last one?
because you CAN upload the .jpg provided as avatar
 
Supervisor

Supervisor

Administrator
Apr 27, 2015
1,863
2,546
335
Nice, so we need to know how to implement code into .gif files.. I did not find a way to do so, but... I guess you know a lot more about that kinda shit, so go and try! :p
 
Supervisor

Supervisor

Administrator
Apr 27, 2015
1,863
2,546
335
The "normal Windows" client won't execute php code. Is it possible to insert other than php code?
 
ehthe

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,028
896
216
nope, you'd need the client or the server to interact with the php binary. And that never happens AFAIK.
 
Last edited:
Asphyxia

Asphyxia

Owner
Administrator
Apr 25, 2015
1,844
2
2,197
327
Possible information related to this or in some way similar?
https://bugzilla.mozilla.org/show_bug.cgi?id=255067 (Comments are very interesting.)
http://www.securityfocus.com/bid/23711/discuss (Meh.. and what type of security site does not support https?!)
http://stackoverflow.com/questions/15800657/exploiting-redundancy-among-jpg-images (Really freaking awesome blog post)
https://www.exploit-db.com/exploits/14268/ (Really fucking cool, could potentially allow us to freeze/crash TS3 servers, if Mumble was vulnerable to it.. TS3 probably is still, lol)

I took this story from wololo.net --- I found it rather interesting to read at the least.
Why we can’t easily find exploits in BMP images
BY WOLOLO · OCTOBER 18, 2009
Last week I gave a short introduction on how to use PSPLink for crash analysis in the XMB. Some people have been actively looking for vulnerabilities on the PSP for years now (yes, it’s a fun hobby, trust me), and crashes, as you already know, can lead to exploits (and exploits lead to homebrews, homebrews lead to anger, and…oh wait… different story).

When they don’t lead to exploits, they lead to bug fixes, which is good too, so understand this: crashing your PSP is good for Mankind.

Recently I got a BMP file from Jeerum (you can get the file on his forum). This file crashes the PSP, and the crash looks like it could have been exploitable, except it isn’t. Rather, this example is a hint that exploiting the PSP using BMP files is probably never going to happen.

An interesting crash
Here’s the video. I’m running the XMB through PSPLink, and if you don’t know how to do this you should consider reading my blog more often.

I’m doing the usual: going to the “images” section (note that the image doesn’t crash the XMB in thumbnail mode, which is quite rare), attempt to display the image, and the PSP crashes.

1lz8IhH.png


Now what’s interesting in this crash? Well as you see, the crash occurs when the PSP tries to Store a Word (MIPS command sw) at an address referenced by register $a1 (sw $t1 8($a1) means: store the value $t1 at $a1+8). And why is it interesting you ask? Well, $a1 is equal to FF414141, and I’m quite convinced that these three “41” come from our BMP file. a value such as FF414141 doesn’t feel “natural” at all, (and that feeling is something you -quickly- get with experience). A quick look at the inside of the BMP file shows us that yes, there’s a bunch of 41’s that were put in there, and it’s quite certain that it’s where the ones we see in the crash come from.

1pdpmtO.png


Now what? Well since we can change these 41’s into what we want, it means we can write the value of t1 pretty much wherever we want in memory. It’s not an exploit yet, but it’s extremely promising.

Not so fast…
But wait… what’s that “FF” doing here?



Advertising


Well that’s the main problem.

To really see where this FF414141 comes from, we can dump the entire contents of the PSP Ram, and check where this comes from.

To dump the Ram to a file, we type the command:
Code: 
savemem 0x08800000 20000000000 memdump1.bin

the 0x08800000 is the start of what we want to dump. 0x08800000 is not an address I chose randomly, it’s just the address of the beginning of the Ram. The second value is the amount of bytes we want to save. As I’m too lazy to calculate, I just enter an insanely high value to be sure all the Ram will be dumped to a file. PSPLink is clever and will stop when it reaches the end. memdump1.bin is the name of the file I want to save.

We can then open this file with an Hex Editor.

EB8bbIq.png


In this screenshot, the addresses I show you are random (because I already investigated this crash a few months ago and I knew what I was looking for), but in reality what you have to do, rather than randomly browsing the memdump, is to understand where the contents of $a1 come from. This is done by disassembling the code around the address of the crash, and understand (through MIPS assembly) where in Ram it read its content. To disassemble code, use the command disasm. I give a few hints on how to do that in my previous articles.

Ok, so the screenshot shows us a bunch of FF414141 in Ram, which is where our value came from. It’s pretty obvious they come from the 41’s we saw in the BMP. These are the contents of the BMP, reinterpreted by the PSP to display pixels on the screen, and this is what we have to deal with if we want to create an exploit.

But wait, we didn’t put thoses “FF”‘s here, only “41”. So where do they come from?

BMP files have no alpha layer
Well to understand this you need some basics in Images on computers. Long story short, pixels on the PSP are represented with 4 bytes, ARGB (alpha, Red, Green, blue). alpha is the transparency of the pixel. Although file formats such as PNG or Tiff have an alpha layer, BMP files don’t. The PSP therefore inserts a “fake” alpha value of “FF” (which means: no transparency) for each pixel.

We’re sc***: whatever we put in the BMP file, every 4 bytes we will get a stupid “FF” inserted as a result in the PSP Ram…

Now it doesn’t mean exploits through BMP files are impossible, but it makes them difficult. Of course, the “original” series of 41’s is maybe stored somewhere else in the Ram, unchanged, but that’s unfortunately not what we deal with in this crash, which makes it useless (if we can’t control all 4 bytes of an address, we’re pretty much sc***).

I don’t think Sony planned this as a security against hackers (they have lots of other tricks against hackers, but this one is probably just the “natural” way of displaying an image with no alpha layer), but it’s still a pretty good security.

The conclusion is that if you are looking for vulnerabilities with images on the PSP, you shouldn’t use image formats that have no transparency layer. Forget about BMPs and Gif, and try to focus on PNGs and Tiffs. It worked in the past.
Click to expand...
 
You must log in or register to reply here.
Top