2

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.

2
  • 1
    you might need to pass a string which contains easily recognizable data in order to see if the frames contain those strings. That might help to understand what exactly is going on. Jan 1, 2016 at 16:32
  • Most probably you overwritten vtable pointer but, it is recommended to do further investigation. For example you can check where are these addresses which computer think it is a pointer reside in stack. Oct 22, 2017 at 8:15

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.