How to Use System Exception Handling Cases to exploit incredible Vulnerabilities

How to Use System Exception Handling Cases to exploit incredible Vulnerabilities

 

Author: [email protected]

0x00 Introduction

The read, write, and execution attributes of memory are one of the most important mechanisms for system security. Generally, to rewrite the data in the memory, you must first ensure that the memory has writable attributes. to execute code in a memory, you must first ensure that the memory has executable attributes, otherwise, an exception occurs. However, there are some small special cases in the exception handling process of Windows systems. With these special cases, you can know that they cannot be written, and that they cannot be executed.

0x01 rewrite read-only memory directly

In the CanSecWest 2014 speech ROPs are for the 99%, I introduced an interesting IE browser vulnerability exploitation technology: disabling the security mode by modifying some signs in JavaScript objects, let IE load similar WScript. dangerous objects such as Shell, so as to execute arbitrary code without considering DEP at all.

However, modifying the SafeMode flag is not the only way for IE to load dangerous objects.

Some interfaces of IE are actually implemented using HTML, which are usually stored in ieframe. dll resources, for example, print and preview is res: // ieframe. dll/preview. dlg. The favorites are res: // ieframe. dll/orgfav. dlg. The page property is res: // ieframe. dll/docppg. ppg.

IE will create independent rendering instances and independent JavaScript Engine instances for these HTML. In the JavaScript engine instances created for these HTML, SafeMode itself is disabled.

Therefore, you only need to insert JavaScript code into ieframe. dll resources, and then trigger the corresponding functions of IE, the inserted code will be executed as the functional code of IE in the JavaScript instance with SafeMode disabled.

However, the PE resource section is read-only. If you attempt to rewrite ieframe. dll resources with a vulnerability that can write data to any address, a write access violation is triggered:

#!basheax=00000041 ebx=1e2e31b0 ecx=00000000 edx=00000083 esi=1e2e31b0 edi=68b77fe5eip=69c6585f esp=0363ac00 ebp=0363ac84 iopl=0         nv up ei pl nz na pe cycs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010207jscript9!Js::JavascriptOperators::OP_SetElementI+0x117:69c6585f 88040f          mov     byte ptr [edi+ecx],al      ds:002b:68b77fe5=760:008> !exchain0363b0f0: jscript9!DListBase
 
  ::DListBase
  
   +1570 (69b421d1)0363b648: jscript9!DListBase
   
    ::DListBase
    
     +1570 (69b421d1)0363bab8: jscript9!DListBase
     
      ::DListBase
      
       +1570 (69b421d1)0363bb78: jscript9!DListBase
       
        ::DListBase
        
         +28c0 (69c71564)0363bbc0: jscript9!DListBase
         
          ::DListBase
          
           +2898 (69c7150f)0363bc44: jscript9!DListBase
           
            ::DListBase
            
             +276a (69d0dedd)0363c588: MSHTML!_except_handler4+0 (66495fa4) CRT scope 0, filter: MSHTML! ... Omitted... (6652bbe8) func: MSHTML!... Omitted... (6652bbf1)0363c62c: user32!_except_handler4+0 (7569a61e) CRT scope 0, func: user32!UserCallWinProcCheckWow+123 (75664456)0363c68c: user32!_except_handler4+0 (7569a61e) CRT scope 0, filter: user32!DispatchMessageWorker+15e (756659b7) func: user32!DispatchMessageWorker+171 (756659ca)0363f9a8: ntdll!_except_handler4+0 (776a71f5) CRT scope 0, filter: ntdll!__RtlUserThreadStart+2e (776a74d0) func: ntdll!__RtlUserThreadStart+63 (776a90eb)0363f9c8: ntdll!FinalExceptionHandler+0 (776f7428)
            
           
          
         
        
       
      
     
    
   
  
 

In the above exception handling chain, the exception handling function in mshtml. dll will eventually call kernel32! RaiseFailFastException (). If the g_fFailFastHandlerDisabled flag is false, the current process is terminated:

#!cppint __thiscall RaiseFailFastExceptionFilter(int this) {  signed int **v1; // [email protected]  CONTEXT *v2; // [email protected]  signed int v3; // [email protected]  UINT v4; // [email protected]  HANDLE v5; // [email protected]  v1 = (signed int **)this;  if ( !g_fFailFastHandlerDisabled )  {    v2 = *(CONTEXT **)(this + 4);    g_fFailFastHandlerDisabled = 1;    RaiseFailFastException(*(PEXCEPTION_RECORD *)this, v2, 2u);    v3 = 1653;    if ( *v1 )      v3 = **v1;    v4 = v3;    v5 = GetCurrentProcess();    TerminateProcess(v5, v4);  }  return 0;}

However, if the g_fFailFastHandlerDisabled flag is true, the exception handling link will be executed to kernel32! UnhandledExceptionFilter (), and finally run kernel32! CheckForReadOnlyResourceFilter ():

#!cppint __stdcall CheckForReadOnlyResourceFilter(int a1) {  int result; // [email protected]  if ( BasepAllowResourceConversion )    result = CheckForReadOnlyResource(a1, 0);  else    result = 0;  return result;}

If BasepAllowResourceConversion is true, the CheckForReadOnlyResource () function sets the attribute of the memory paging page to writable and returns the result normally.

That is to say, if you first rewrite the g_fFailFastHandlerDisabled and BasepAllowResourceConversion flags to true, then you can directly modify ieframe. dll resources without worrying about its Read-Only attributes. The operating system will handle everything well.

There is also a small problem. If a memory Attribute Modification Operation in CheckForReadOnlyResource () is triggered as mentioned above, the RegionSize of the Memory attribute will also change to a memory page size, usually 0x1000. Before IE creates a rendering instance for HTML resources in ieframe. dll, mshtml! The GetResource () function checks the RegionSize attribute of the memory where the resource is located. If this attribute is smaller than the resource size, a failure is returned. However, you only need to rewrite all the resources from start to end, and the RegionSize will increase accordingly, bypassing this check.

In this way, the use of Windows write access exceptions to the PE file resource section green light, you can write a very wonderful vulnerability exploitation code.

0x02 direct execution of unexecutable memory

In my speech "time dimension in vulnerability mining" in VARA 2009, I introduced a rare module address that can be reused after being released. For example, thread A in A program calls the function of module X, and module X calls the function of module Y. For some reason, the function of module Y takes a long time to return. Before it returns, if thread B can release module X, the return address of module Y is invalid. At that time, it was found that the Flash module could be used in operabrowser to trigger this vulnerability. A Chinese download tool also had a similar problem.

In addition, there are many other types of vulnerabilities, and the final performance is the same as the above problem. A fixed pointer can be executed, but the value of this pointer cannot be controlled. In a DEP-free environment, these vulnerabilities are not difficult to exploit, as long as the code is injected into the address where the code is executed. In the DEP environment, these vulnerabilities are generally considered impossible to use.

However, if the following data is sprayed at the address that is expected to be executed:

#!cpptypedef struct _THUNK3 {    UCHAR MovEdx;       // 0xba         mov edx, imm32    LONG EdxImmediate;     UCHAR MovEcx;       // 0xb9         mov ecx, imm32    LONG EcxImmediate; // <- put your Stack Pivot here    USHORT JmpEcx;      // 0xe1ff       jmp ecx} Thunk3;

Even in the DEP environment, although the memory area of the heap injection is definitely not executable, you will be surprised to find that the system seems to have executed these commands and jumped to the address set by ecx. You only need to set ecx as a proper value, and you can jump to any address and then execute the drop-down chain.

This is because Windows has implemented a mechanism called ATL thunk emulation to be compatible with earlier versions of programs. When processing an access exception, the system kernel checks whether the code at the exception address conforms to the ATL thunk feature. For codes that conform to the ATL thunk features, the kernel uses the KiEmulateAtlThunk () function to simulate and execute them.

The ATL thunk emulation mechanism checks whether the address to be jumped is in the PE file. On the CFG-supported system, it also determines whether the address to be jumped can pass the CFG check. In addition, in Windows Default DEP policy after Vista, the ATL thunk emulation mechanism takes effect only for programs without IMAGE_DLLCHARACTERISTICS_NX_COMPAT. If the/NXCOMPAT parameter is specified during program compilation, it is no longer compatible with ATL thunk emulation. However, many programs support ATL thunk emulation, such as many third-party applications and 32-bit iexplore.exe. So, similar to the Hacking Team leaked the CVE-2015-2425 in the mail, If you can use a certain heap spray to successfully seize the memory, you can also use this technique to achieve vulnerability exploitation.

In this way, the ATL thunk emulation in the system exception handling process can be used to directly execute the unexecutable memory feature, which can bring back some vulnerabilities that are generally considered unusable.

(Most of the content in this article was completed in October 2014. The module address and symbolic information involved are based on Windows Technical Preview 6.4.9841 x64 with Internet Explorer 11 .)

0x03 references ROPs are for the 99%, CanSecWest 2014 Bypassing Browser Memory Protections (CVE-2015-2425) "Gifts" From Hacking Team Continue, IE Zero-Day Added to Mix time dimension in vulnerability mining, VARA 2009