miércoles, octubre 04, 2006

Elf infection adding new section

The No cON Name 2006 security congress celebrated at Palma de Mallorca, i have presented a possible solution to code vulnerabilities like buffer overflows.

Here is the link: http://www.noconname.org/congreso2006.php

I prensented some current solutions like pax, W^X, address layout randomizations, etc and show their main limitation: doesnt solve the real problem, when overflow happens, there are many traps to prevent the execution of code but the overflow happened yet and with time, attackers will redirect execution and will inject a payload somewhere.

I have shown the real problem: at post-compilation there are no variable-sizes, only exists pointers to the beginning of variables but not the end either the size.

Is it possible to calculate the limits of almost all variables, by reading dinamyc memory calls, and analyzing the use of the stack pointers.

I proposed the idea of a binary regenerator, that study the pointer bounds, and correct the instructions that want to violate this boundaries. In order to repair the code i show some virus infection, cold-patching and hot patchin techiniques.

Instead of replacing code by inline-patching, i suggested to make a call a .regen section and there is the code sanitizeed, in order to recover the bad-code if needed.


Why current protections are dificulting the explotation instead of solve the problem?
May the compilers store the variable sizes at de elf and PE executables?

I think this will solve most of security problems.

[spanish]
En el congreso 2006 de seguridad informática celebrado en palma de mallorca (noconname.org) he presentado una solución a los problemas de desbordamientos de pila, basandose en localizar límites y parchear el código vulnerable.

El parcheo o infección de código lo realizan los virus informáticos, podemos aplicar muchas partes de ellos en la seguridad.

De los diversos tipos de infección que hay (overlay, crecimiento de .text, seccion nueva, etc ..) hablaré de una en concreta que para este caso es más eficaz.

El objetivo es poder corregir el código binario y dejar el código corregido en otra seccion (.patch)

Infección mediante creación de sección:
(en este procedimiento no se va a agrandar shstrtab para incluir ahi el nombre de sección ya que la sección que contiene nombre de secciones no es mapeada en tiempo de ejecución)

1. Remapear con el tamaño del fichero+parche+1 registro de sección
2. Desplazamiento lógico del offset y virtual de las secciones inferiores a la tabla de secciones
3. Desplazamiento físico de las secciones inferiores a la tabla de secciones
4. Añadir nueva sección semejante a .text con flags progbits, alocatable y ejecutable. Y aumentar e_shnum
5. Agrandamiento lógico de segmento de texto en el tamaño del parche
6. Desplazamiento lógico de los segmentos inferiores al de texto (offset y virtual)
7. Desplazamiento lógico de las secciones inferiores al antiguo final del segmento de texto (offset y virtual)
8. Desplazar físicamente lo que haga por debajo del inicio de .patch (final del antiguo segmento texto) para que quede espacio para .patch
9. Actualizar e_shoff ya que se ha desplazado físicamente la tabla de secciones (está abajo)
10. Guardar la nueva versión corregida de las funciones vulnerables en .patch y reapuntar sus calls a esta sección.





EOF

1 comentario:

Anónimo dijo...

Tendrias que hacer un doc un poco más amplio con el trasfondo adecuado. Similar al doc de rootkits que hice (q aunque no sea una maravilla es un ejemplo) en el que se explica todo linea por linea explicando el por qué, de manera que una persona sin haber leido el doc ni saber excesivamente pueda aprovechar ese conocimiento que explicas.

un saludo.

JMP_