A heap-based buffer overflow can occur when calling the undocumented "sp_replwritetovarbin" extended stored procedure. This vulnerability affects all versions of Microsoft SQL Server 2000 and 2005, Windows Internal Database, and Microsoft Desktop Engine (MSDE) without the updates supplied in MS09-004. Microsoft patched this vulnerability in SP3 for 2005 without any public mention. An authenticated database session is required to access the vulnerable code. That said, it is possible to access the vulnerable code via an SQL injection vulnerability. This exploit smashes several pointers, as shown below. 1. pointer to a 32-bit value that is set to 0 2. pointer to a 32-bit value that is set to a length influenced by the buffer length. 3. pointer to a 32-bit value that is used as a vtable pointer. In MSSQL 2000, this value is referenced with a displacement of 0x38. For MSSQL 2005, the displacement is 0x10. The address of our buffer is conveniently stored in ecx when this instruction is executed. 4. On MSSQL 2005, an additional vtable ptr is smashed, which is referenced with a displacement of 4. This pointer is not used by this exploit. This particular exploit replaces the previous dual-method exploit. It uses a technique where the value contained in ecx becomes the stack. From there, return oriented programming is used to normalize the execution state and finally execute the payload via a "jmp esp". All addresses used were found within the sqlservr.exe memory space, yielding very reliable code execution using only a single query. NOTE: The MSSQL server service does not automatically restart by default. That said, some exceptions are caught and will not result in terminating the process. If the exploit crashes the service prior to hijacking the stack, it won't die. Otherwise, it's a goner.
Windows
To display the available options, load the module within the Metasploit console and run the commands 'show options' or 'show advanced':
Time is precious, so I don’t want to do something manually that I can automate. Leveraging the Metasploit Framework when automating any task keeps us from having to re-create the wheel as we can use the existing libraries and focus our efforts where it matters.
– Jim O’Gorman | President, Offensive Security