I'm trying to reverse engineer a library function code vulnerable to a buffer overrun to properly determine both the cause and the risks associated with it, but there is a behaviour I'm not sure to exactly understand.
The scenario is as follows:
- W64 application on Windows 8.1 which instantiates a COM object (a library).
- The library is prone to a buffer overrun with user controled input. No EIP gets overriten as library was compiled with MS Visual Studio /GS options (Stack canary protection)
- Private symbols of an older version of the library are available, so I can force them to load with .reload /i
- After calling to the function ProcessMessage, a 1023 bytes output buffer is filled with user controled input,for example a string with 2048 bytes.
- After return from this function ProcessMessage, stepping with the debugger raises messages of type "Unable to read dynamic function table entry at ....".
This is the offending calling code:
lea r9,[rsp+78h] ;* _EVENT_DATA_DESCRIPTOR lea rdx,[rsp+40h] ; format string in data section (.... %s) mov r8d,1 ; # of _EVENT_DATA_DESCRIPTORs mov dword ptr [rbp-80h],eax ;stringLen of data in _EVENT_DATA_DESCRIPTOR mov dword ptr [rbp-7Ch],esi call qword ptr [Library!ADVAPI32_NULL_THUNK_DATA] ;call to EtwEventWrite call qword ptr [Library!_imp_PeekNamedPipe ;calls GetCommandLineW lea rdx,[Library!$xdatasym+0x70] ;format string in data section (.... %s) lea rcx,[rbp-60h] ;output buffer which will store result of ProcessMessage and will get overrun mov r8,rax ;result of _imp_PeekNamedPipe. Will used together with format string in rdx to form a string and store it in output buffer in rcx call Library!`VulnerableClass::ProcessMessage'::`1'::catch$0+0x38
Aftet the call to ProcessMessage, the following messages appear debugging with Windbg:
0:013> p Unable to read dynamic function table entry at 00007ff801642c90 Unable to read dynamic function table entry at 00007ff801642cd0 0:013> p Unable to read dynamic function table entry at 00007ff801642c50 Unable to read dynamic function table entry at 00007ff801642c90
Does those messages mean our overflowed buffer has overwritten the vtable pointer of an object in the stack which has virtual methods? If so, is it possible to know to which object or functions does those addresses belong? Doing a u or dd on those address show no results.
In case it helps, the exceptions handlers declared, except of the current stack frame, were overwritten as well by user input (a mona.py pattern as shown below), don't know exactly if it has to do anything with the messages about dynamic function table:
0:013> !exchain 31 stack frames, scanning for handlers... Frame 0x00: Library!VulnerableClass::SetValue+0x88b ehandler Library!`operator new'::`6'::`dynamic atexit destructor for 'nomem''+0x6490 Frame 0x01: error getting module for 3462413362413262 Frame 0x02: error getting module for 307a5a6241356241 Frame 0x03: error getting module for 7a5a327a5a317a5a
Thank you very much for the answers.