Web Server / HTTP API Remote Exploits (Please Read!) [Updated]
#1
A few remote exploits were brought to our attention recently and have been fixed in r19126. It is recommend that you disable the web server until you can get a build at or later than this one installed. This goes double if you're doing something stupid like running XBMC on a priveleged account or exposing the server to the internet.

All database access through the httpapi has been disabled until a denial of service, in the form of a segfault, can be resolved.

A HUGE thanks goes out to n00b for the security audit and PoC code. Keep up the good work!

EDIT: You can disable the web server in settings > network > servers.

UPDATE: All the exploits reported by n00b should be fixed as of r19131. Of course running XBMC on a privileged account and exposing the servers to the Internet is still not advised. -d4rk.
Reply
#2
Hi im a security researcher i fund my own hobbies and don't get paid from any one for the advisory i release its all done purely as a hobbie.

I'm glad i was able to help towards the project in some way.Im pleased all the buffer overflows got fixed that is great news and only in a short period of time i can only thank the developers for listening to me when i come to irc.

If you had refused to talk to me about the matter i would have just released the poc to the public this is because some vendors do not take things seriously.

Its like they brush it under the carpet and cross there figures and hope it goes away or instead of adding some length checking they compile the binary with /gs flag and think that its safe.

In order to rectify these problems you have to modify it from a code perspective not just hoping that a /gs cookie will save the day.
Because there are ways of bypassing that also.

The buffer overflows i released could potential ruin your day so i would
advise every one who has the out dated version to grab it straight away. these buffer overflows are not only restricted to exploiting a machine in your own local network if you are running the application on windows especially i would say your most at risk.

And as for fire walls we can by pass these no matter what filtering you have or hardware we can use a connect back shell code and bypass these restrictions.

Afew notes i wanted to add for the developers which could need to be rectified there is no warning message when the server goes off line maybe a little added error handling maybe a good option.

Why is it when the exploit takes place the only thing that is affected is the http server.When i was debugging the process i noticed the thread died and the execution off the shell code carried on as normal the application carried on as normal.

I was also able to bypass your url filtering by placing my shell-code into the 2-3 poc code.This meant any shell code could be executed with not much difficuilty and i didnt have to sift through all the bad charactors.

I will be looking into a little more of xbmc application in the near future i have your email addy and will contact you.

If any one feels they dont understand the risk you can also pm its not a problem.

Big Grin
Reply
#3
Good info for sure.. thanks for lookin out.

This is why I prefer hardware based firewalls, real firewalls, not d-links or simple nat based routers. Enterprise grade hardware firewalls rock at keeping folks from getting into your network.. a nice old linux box with a few nics and some config time can do wonders as well.

Quote:And as for fire walls we can by pass these no matter what filtering you have or hardware we can use a connect back shell code and bypass these restrictions.
I agree that for the most part 90% of what's out there is junk, however...
With the right firewall(s) and config, you can make a bulletproof network. It's very complex and most folks are not going to do it, not to mention it's a major pain in the rear to allow traffic when you want to.
Reply
#4
Hi fekker i hear what your saying about the right kind of configuration being able to limit the connectivity to the port and filters might help.
But we know allot of people struggle to set up a normal firewall never mind restricting access.

If it would have been local exploit no matter how much filtering or hardware fire wall you had you would be voulnrable.This is because normally a bind shell code would do the following

Normal shell code
client >>>server

Reverse bin shell code
server >>>client.

And to allow the server only when you need really defeats the object of the whole matter Smile

But i know as with the local exploitation nothing much would help you i saw multi dollar organizations getting owned with switches and firewalls in place.
still fall to such attack.

this allows us to bypass fire walls no matter what hard-ware you have in place.

Just to add one more thing to the discussion i was able to over write the
exception handlers on the stack with no problem and was able to execute shell code and also have an universal address to return to.Means vista address randomization wont help you in this case.

Some of the dll which are shipped with your application are not compiled with out safe seh.This is not down to you guys though.

/SafeSEH Module Scanner, item 56
SEH mode=/SafeSEH OFF
Base=0x62e40000
Limit=0x62e60000
Module version=1, 2, 6, 0
Module Name=C:\Program Files\XBMC\SDL_image.dll

/SafeSEH Module Scanner, item 57
SEH mode=/SafeSEH OFF
Base=0x330000
Limit=0x366000
Module version=1,5,0,0
Module Name=C:\Program Files\XBMC\glew32.dll

It was easy to accomplish this by over writing the seh chain and all i had to do was jump 6 bytes down the stack and pop ebx pop return back in the stack and the shell code was executed once again this was tested on a vista machine.

Pointer_To_Next_SEH = over wrote with a 6byte jump
SE_Handler = pop ebx pop ret
shellcode.

What this means is i did not have to direct the flow of execution via overwriting the $eip register
and makes for a much reliable exploit method.Any way enough rambling from me.
Reply
#5
First of all sorry for the double post i played this week end with the buffer overflow and managed to borrow a lap top running vista sp1 and did get code execution like i described above Smile.

So don't stall with the delay of updating your system.

Don't think address randomization on vista will help you.

the address i used is the following..

###This was found in the module zlib1 and is universal.
#62E83BAC 5B POP EBX
#62E83BAD 5D POP EBP
#62E83BAE ^E9 CDD9FFFF JMP zlib1.compressBound
Reply

Logout Mark Read Team Forum Stats Members Help
Web Server / HTTP API Remote Exploits (Please Read!) [Updated]0