significado - que es stack overflow

Utilice un desbordamiento de pila para escribir datos arbitrarios

Question

He estado tratando de aprender los conceptos básicos de un ataque de desbordamiento de montón. Estoy principalmente interesado en utilizar una corrupción o modificación de los metadatos de la porción para la base del ataque, pero también estoy abierto a otras sugerencias. Sé que mi objetivo del exploit debería ser sobrescribir el puntero de la función printf() con el del puntero de la función challenge() , pero parece que no puedo encontrar la forma de lograr esa escritura. Tengo el siguiente fragmento de código que quiero explotar, que está usando malloc de glibc 2.11.2 :

void challenge()
{
        puts("you win/n");
}

int main(int argc, char **argv)
{
        char *inputA, *inputB, *inputC;

        inputA = malloc(32);
        inputB = malloc(32);
        inputC = malloc(32);

        strcpy(inputA, argv[1]);
        strcpy(inputB, argv[2]);
        strcpy(inputC, argv[3]);

        free(inputC);
        free(inputB);
        free(inputA);

        printf("execute challenge to win/n");
}

Obviamente, lograr una sobrescritura real de los metadatos de un fragmento asignado es trivial. Sin embargo, no he podido encontrar una manera de explotar este código usando ninguna de las técnicas estándar. He leído e intentado implementar las técnicas de:

• El documento: w00w00 en desbordamientos de pila
  • Aunque el papel es muy claro, la técnica de unlink ha estado obsoleta por algún tiempo.
• Malloc Maleficarum.txt
  • Este documento expande las técnicas de explotación de los días de w00w00 y explica las versiones más recientes de glibc. Sin embargo, no he encontrado que, dadas las 5 técnicas detalladas en el documento, el código anterior coincida con cualquiera de los requisitos previos para esas técnicas.
• Entendiendo el montón rompiéndolo (pdf)
  • El pdf ofrece una buena revisión de cómo funciona el montón, pero se enfoca en técnicas de doble libre.

Originalmente traté de explotar este código manipulando el valor del tamaño del fragmento para inputC, de modo que apuntara de nuevo a la cabeza del fragmento inputC. Cuando eso no funcionó, intenté volver a señalar el trozo de inputB. Fue entonces cuando me di cuenta de que el nuevo glibc realiza una comprobación de validez en el valor del tamaño.

¿Cómo puede un usuario crear un exploit para aprovechar un libre, suponiendo que tiene la capacidad de editar los metadatos del fragmento asignado a valores arbitrarios, y usarlo para sobrescribir un valor en el GOT o escribir en cualquier otra dirección arbitraria?

Nota: Cuando escribo "dirección arbitraria", entiendo que las páginas de memoria pueden ser de solo lectura o protegidas, me refiero a una dirección en la que puedo asumir que puedo escribir.

Answer 1

Los desbordamientos de pilas son difíciles de realizar y dependen mucho del diseño de la pila, aunque parece que vas tras la pila CRT de Windows, que tiene muchas mitigaciones específicamente para detener este tipo de ataque.

Si realmente quieres hacer este tipo de cosas, necesitas saltarte feliz en WinDbg y acceder a funciones como free para ver exactamente lo que está sucediendo dentro de forma gratuita, y por lo tanto, qué tipo de control podrías lograr a través del montón Desbordamiento del valor anterior.

No le daré más ayuda específica que esa por la simple razón de que demostrar un desbordamiento del montón suele ser suficiente para la seguridad defensiva; los expertos en seguridad defensiva pueden informar sobre un desbordamiento del montón sin necesidad de explotarlo por completo. Las únicas personas que necesitan explotar completamente un desbordamiento del montón hasta la ejecución remota de código son las personas que explotan los errores de manera ofensiva , y si quieres hacerlo, estás por tu cuenta.

Answer 2

Nota: Antes de responder, debo decir que se trata de una respuesta puramente académica, que no debe utilizarse con fines maliciosos. Soy consciente de los ejercicios que está haciendo OP y son de código abierto y no tienen la intención de alentar a los usuarios a usar estas técnicas en circunstancias no aprobadas.

A continuación detallaré la técnica, pero para su referencia, echaría un vistazo a los trucos de Vudo malloc (se hace referencia en uno de sus enlaces anteriores) porque mi resumen será breve: http://www.phrack.com/issues.html?issue=57&id=8

Detalla cómo malloc maneja la creación de bloques de memoria, extrayendo memoria de listas y otras cosas. En particular, el ataque de desvinculación es de interés para este ataque (nota: tienes razón al decir que glibc ahora realiza un control de cordura en los tamaños por esta razón en particular, pero deberías estar en una libc más antigua para este ejercicio ... hermano legado).

En el documento, un bloque asignado y un bloque libre utilizan la misma estructura de datos, pero los datos se manejan de manera diferente. Mira aquí:

chunk -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | prev_size: size of the previous chunk, in bytes (used   |
         | by dlmalloc only if this previous chunk is free)        |
         +---------------------------------------------------------+
         | size: size of the chunk (the number of bytes between    |
         | "chunk" and "nextchunk") and 2 bits status information  |
  mem -> +---------------------------------------------------------+
         | fd: not used by dlmalloc because "chunk" is allocated   |
         | (user data therefore starts here)                       |
         + - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
         | bk: not used by dlmalloc because "chunk" is allocated   |
         | (there may be user data here)                           |
         + - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
         |                                                         |
         |                                                         |
         | user data (may be 0 bytes long)                         |
         |                                                         |
         |                                                         |
 next -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | prev_size: not used by dlmalloc because "chunk" is      |
         | allocated (may hold user data, to decrease wastage)     |
         +---------------------------------------------------------+

Los bloques asignados no utilizan los punteros fd o bk, pero sí los libres. Esto va a ser importante más adelante. Debe saber suficiente programación para comprender que los "bloques" en el malloc de Doug Lea están organizados en una lista con doble enlace; hay una lista para los bloques libres y otra para los asignados (técnicamente, hay varias listas gratuitas según los tamaños, pero aquí es irrelevante ya que el código asigna bloques del mismo tamaño). Así que cuando liberas un bloque en particular, debes corregir los punteros para mantener la lista intacta.

Por ejemplo, digamos que está liberando el bloque y de la lista siguiente:

x <-> y <-> z

Observe que en el diagrama de arriba, los puntos para bk y fd contienen los punteros necesarios para iterar a lo largo de la lista. Cuando malloc quiere quitar un bloque p de la lista, llama, entre otras cosas, una macro para arreglar la lista:

#define unlink( y, BK, FD ) {            
    BK = P->bk;                          
    FD = P->fd;                          
    FD->bk = BK;                         
    BK->fd = FD;                         
}

La macro en sí no es difícil de entender, pero lo importante a tener en cuenta en las versiones anteriores de libc es que no realiza controles de validez en el tamaño o en los punteros que se escriben. Lo que significa en su caso es que sin ningún tipo de asignación aleatoria de direcciones puede predecir y confiablemente determinar el estado del montón y redirigir un puntero arbitrario a una dirección de su elección desbordando el montón (a través de la copia aquí) de una manera específica .

Hay algunas cosas que se requieren para que el ataque funcione:

• el puntero fd de su bloque apunta a la dirección que desea sobrescribir menos 12 bytes. El desplazamiento tiene que ver con malloc que limpia la alineación cuando modifica la lista
• El puntero bk de su bloque apunta a su código de shell.
• El tamaño debe ser -4. Esto logra algunas cosas, es decir, establece los bits de estado en el bloque

Así que tendrás que jugar con las compensaciones en tu ejemplo específico, pero el formato malicioso general que intentas pasar con la clave aquí es del formato:

| basura para llenar el buffer legítimo | -4 | -4 | addr que quiere sobrescribir -12 (0x0C) | addr desea llamar en su lugar

Tenga en cuenta que el número negativo establece el campo prev_size en -4, lo que hace que el enrutamiento libre crea que la porción prev_size en realidad comienza en la porción actual que usted controla / está corrompiendo.

Y sí, una explicación adecuada no estaría completa sin mencionar que este ataque no funciona en las versiones actuales de glibc; el tamaño tiene un control de cordura hecho y el método de desvinculación simplemente no funciona. Que en combinación con mitigaciones como la aleatorización de direcciones hace que este ataque no sea viable en nada más que en sistemas heredados. Pero el método descrito aquí es cómo hice ese desafío;)

Answer 3

Tenga en cuenta que la mayoría de las técnicas explicadas en Malloc Malleficarum ahora están protegidas. El glibc ha mejorado mucho todos esos escenarios libres dobles.

Si desea mejorar su conocimiento sobre las técnicas de Malloc Malleficarum, lea el Malloc Des-Malleficarum y la House of Lore: Reloaded escrito por blackngel. Puedes encontrar estos textos en phrack.

Malloc Des-Malleficarum

También estoy trabajando en ello, y puedo decirles que, por ejemplo, House of Mind ya no es explotable, al menos, como se explica en los textos. Aunque podría ser posible eludir las nuevas restricciones agregadas al código. Agregue que la forma más fácil de ejecutar su código es sobrescribir la dirección de .dtors, por lo tanto, su código siempre se ejecutará una vez que finalice el programa.

Si descarga el código glibc y estudia las zonas críticas de malloc., Etc., encontrará comprobaciones de código que no están documentadas en los documentos mencionados anteriormente. Estos cheques fueron incluidos para detener la doble fiesta gratis.

Por otro lado, la presentación de Justin N. Ferguson (Entendiendo el montón al romperlo) que puedes encontrar en youtube (BlackHat 2007) es perfecta para entender todas las mecánicas del montón, pero debo admitir que las técnicas mostradas son lejos de ser confiable, pero al menos, abre un nuevo campo para apilar la explotación.

Entendiendo el montón rompiéndolo

De todos modos, también estoy trabajando en ello, así que si quiere contactarme, podemos compartir nuestros avances. Puede contactarme en el dominio overflowedminds.net como newlog (compile la dirección de correo usted mismo ^^).