PornoSecurity

MS SQL Server sp_replwritetovarbin Heap Overflow

Posted on 2008-12-18 11:34:18 in PornoSecurity

The vulnerability is in the "sp_replwritetovarbin()" SQL procedure and can be exploited to cause a heap-based buffer overflow. I wrote an exploit in the form of an ASP page that uses four queries to write four bytes to a writable address and that uses this address to overwrite a function pointer. I also managed to modify a metasploit shellcode to allow multiple shots withouth crashing the SQL server. I tested it only on Win2k SP4 and only on one box, maybe I will try with SQL 2005 and Win2k3.

The good thing is that it is still unpatched and it is possibile to exploit this vuln simply by injecting the T-SQL stuff using an SQL Injection :)

Check it out here!

Nick  

2008-12-18 14:14:10  

w0lf: hello frist of all i should say good job :) exploiting this case on win2k3 box is really difficulter than win2k box . because you should bypass a dozen of protections such as NX(DEP) , GS , SAFESEH , (heap) safe unlinking , re to MSSQL 2005 compilation , mssql have GS and there is no 3dparty dll with safeseh off . and also re to win2k3 implementation DEP is opt-out (there is a change in default configuration using pre-process disabling DEP using Skape/ Skywing method ) but as you know dep alwayeOn is bypassed too but there is no public article about this subject . and i think the good payload for this exploit in pen-test cases are add user and reverse shell. i,m really hope to see your exploit for mssql 2000 /2005 on win2k3 box . have a nice exploitation !

---

2008-12-18 14:45:42  

k`sOSe: hello w0lf, thank you :) I hope somebody will include the sploit in something like sqlmap or sqlninja, if not I will probably do it by myself Unfortunately I have not much time to work on this. Regarding SQL2005 and Win2k3: GS should not be a problem here, disabling DEP at runtime is pretty easy if you can arrange the right stack frame. This overflow corrupt data on the heap but i'm pretty sure it is possibile to reuse some pointers that reside on the stack. The real problem is how much time it needs to do that.

---