Tarea

Evitando SEHOP por SYSDREAM IT Security Services traducido por Ivinson/CLS

Evitando SEHOP por SYSDREAM IT Security Services traducido por Ivinson/CLS

Stéfan Le Berre s.leberre@sysdream.com Damien Cauquil d.cauquil@sysdream.com

Evitando SEHOP por SYSDREAM IT Security Services traducido por Ivinson/CLS

Tabla de contenidos 0. Introducción…………………………………………………….……….4 1. Especificacionesdel SEHOP (versión corta)………….……….………..4 2. Tratar con SEHOP al explotar un desbordamiento de pila…….………..7 2.1 Romper con el esquema de explotación clásica………...….…….…..7 2.2 La parte difícil…………………………………………………….….8 3. Prueba de Concepto (PoC)…………………………………………..…..9 3.1.Programa objetivo y las limitaciones………………………….……..9 3.2.Error y Explotación…………………………………………..………9 4.Conclusión……………………………………………………….…...…11 5. Créditos……………………………………………….………….……..11 6. Bibliografía…………………………………………………….………..12

Evitando SEHOP por SYSDREAM IT Security Services traducido por Ivinson/CLS

0. Introducción
Microsoft ha implementado recientemente en muchas versiones de Windows una nueva característica de seguridad llamada: « Protección de sobreescritura del Manejo estructurado de excepciones» [1 y 2]. Estos sistemas son: • Microsoft Windows 2008SP0. • Microsoft Windows Vista SP1. • Microsoft Windows 7. No se encontró ningún ataque conocido destinado a derrotar esta nueva característica, sino muchos papeles describiendo la función de sí misma y su robustez. En efecto, SEHOP parece ser tan fiable que Microsoft lanzó un parche para activar esta función de seguridad de forma predeterminada en todos los programas. ¿Ya es el final dedesbordamientos de pila en Microsoft Windows? Todavía no, pero bajo algunas circunstancias, como explicaremos a continuación. 1. Especificaciones del SEHOP (versión corta) SEHOP es una extensión de Manejo estructurado de excepciones e implementa más controles de seguridad en las estructuras SEH utilizadas por los programas. La característica principal de SEHOP comprueba el encadenamiento de todos lasestructuras SEH presentes en la pila del proceso y sobre todo la última, que debe tener un valor de manejador especial apuntando justo a una función ubicada en ntdll. Aquí hay una cadena de SEH clásica:

Evitando SEHOP por SYSDREAM IT Security Services traducido por Ivinson/CLS

Cada estructura de SEH apunta a la siguiente estructura y la última contiene un manejador específico que apunta a ntdll_except_handler4. Cuando explotamos sobrescribiendo una estructura SEH en la pila, el puntero del próximo SEH se sobrescribe con el fin de contener algún bytecode y el manejador SEH es sobrescrito para que apunte a una secuencia de instrucciones «POP POP RET» que se encuentran en un módulo sin SafeSEH. El algoritmo de validación utilizado en SEHOP ha sido expuesto por A. Sotirov durante el BlackHat en el año 2008 [3]. Vamos a echar un vistazo:
BOOL RtlIsValidHandler(handler) { if (handler is in an image) { if (image has the IMAGE_DLLCHARACTERISTICS_NO_SEH flag set) return FALSE; if (image has a SafeSEH table) if (handler found in the table) return TRUE; else return FALSE; if (image is a .NET assembly with the ILonly flag set) return FALSE; // fall through } if (handler is on anon-executable page) { if (ExecuteDispatchEnable bit set in the process flags) return TRUE; else // enforce DEP even if we have no hardware NX raise ACCESS_VIOLATION; } if (handler is not in an image) { if (ImageDispatchEnable bit set in the process flags) return TRUE; else return FALSE; // don't allow handlers outside of images } // everything else is allowed return TRUE; } [...] // Skip the chainvalidation if the DisableExceptionChainValidation bit is set if (process_flags & 0x40 == 0) { // Skip the validation if there are no SEH records on the // linked list if (record != 0xFFFFFFFF) { // Walk the SEH linked list do { // The record must be on the stack if (record < stack_bottom || record > stack_top) goto corruption; // The end of the record must be on...