Pointer Redirecting

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Punteros de cadena

Si una llamada a función va a usar la dirección de una cadena que está ubicada en el stack, es posible abusar del buffer overflow para sobrescribir esta dirección y poner dentro del binario la dirección de una cadena diferente.

Si por ejemplo una llamada a la función system va a usar la dirección de una cadena para ejecutar un comando, un atacante podría colocar la dirección de otra cadena en el stack, export PATH=.:$PATH y crear en el directorio actual un script con el nombre de la primera letra de la nueva cadena ya que este será ejecutado por el binario.

En objetivos reales, reapuntar un puntero de cadena en el stack suele ser más interesante que simplemente cambiar el texto impreso:

  • Redirigir más tarde un argumento de system/popen/execl* hacia un "/bin/sh" ya existente o hacia una cadena de comando controlada por el atacante que ya esté presente en memoria.
  • Redirigir un sink de read posterior como puts("%s", ptr) o write(fd, ptr, len) para leak información del stack, heap o del binario.
  • Redirigir un sink de write posterior como strcpy(dst, ...), memcpy(dst, src, len), o una asignación de campo de estructura a través de ptr->field = value para convertir el overflow en una escritura arbitraria de segunda etapa.

Al auditar, prioriza locales en el stack como char *cmd, char *path, char *buf, FILE *fp, o pointers dentro de structs temporales de request/response que se usan después del overflow pero antes de que la función retorne. Esto es especialmente útil cuando el overflow no puede alcanzar de forma segura la return address guardada por culpa de un canary o porque corromper un puntero cercano es suficiente.

Si la corrupción está limitada a una sobrescritura parcial (por ejemplo porque el bug añade un 0x00), intenta redirigir el puntero hacia:

  • Una cadena cercana en el mismo stack frame
  • Otro objeto en el mismo módulo / imagen non-PIE
  • Una región controlada cuyas bytes altas permanezcan sin cambiar

Para el caso relacionado orientado a ASLR donde un NUL final modifica un puntero de stack existente en lugar de una variable local dedicada, consulta Ret2ret & Reo2pop.

Puedes encontrar un ejemplo de esto en:

Punteros a funciones

Igual que con punteros de cadena pero aplicado a funciones: si el stack contiene la dirección de una función que será llamada, es posible cambiarla (p. ej. para llamar a system).

Los objetivos útiles no son sólo variables de callback explícitas como void (*fp)(). En la práctica, busca:

  • Callbacks almacenados en structs locales pasados más tarde a helper functions
  • Destructor / cleanup handlers invocados en paths de error
  • Parser dispatch tables o state-machine handlers copiados al stack
  • Structs / objetos locales que luego hacen dispatch a través de una llamada indirecta

En la explotación moderna, pointer redirection suele ser el último primitive disponible antes de tocar el canary. Un writeup de explotación de 2024 para CVE-2024-20017 muestra el patrón típico: el overflow alcanza varias variables locales antes del stack canary, el atacante corrompe un puntero en el stack más su longitud/valor asociado, y una asignación posterior a través de ese puntero se convierte en una escritura arbitraria sin necesidad de retornar nunca a través del frame corrompido.

Corrupción de punteros para primitives de segunda etapa

Si un puntero cercano es posteriormente desreferenciado para una store, el objetivo normalmente no es saltar directamente con el primer overflow, sino mejorar el primitive:

  1. Desbordar un buffer local y corromper un puntero más cualquier longitud / entero / índice asociado.
  2. Esperar a que la función haga una desreferencia post-overflow como ptr->len = x, memcpy(ptr, src, n) o *ptr = value.
  3. Usar esa write-what-where resultante para sobrescribir una entrada de la GOT, un callback, un puntero de configuración, o otro sitio de llamada indirecta.

Esta es una buena opción cuando:

  • El bug se detiene en el canary
  • El function pointer en sí no es directamente alcanzable
  • Una escritura de datos de 4 bytes u 8 bytes es más fácil de conseguir que un secuestro inmediato del control-flow

La misma idea también funciona para primitives de read si el puntero corrompido se pasa más tarde a helpers de logging, printing, o network send.

Modern AArch64 note: PAC / BTI

En targets AArch64 actuales, un clásico sobrescribir la return address guardada puede fallar porque el epílogo autentica x30 con PAC. En esos casos, los secuestros no-retorno como punteros locales a funciones corrompidos o punteros de callback se vuelven más atractivos.

Sin embargo, si BTI está habilitado, el objetivo de la llamada indirecta sobrescrita aún debe aterrizar en un landing pad válido (típicamente una entrada de función con bti c, o en código con PAC habilitado un prologue que empiece con paciasp/pacibsp). Por lo tanto, al redirigir un puntero de función en el stack en AArch64, prefiere:

  • Entradas reales de función en lugar de gadgets mid-function
  • Objetivos cuyo prólogo ya satisface BTI
  • Objetivos donde el puntero de llamada indirecta no sea adicionalmente autenticado antes de su uso

Para un contexto relacionado de stack-overflow en AArch64, consulta ret2win-arm64.

Puedes encontrar un ejemplo en:

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks