+
+
+#include
+
+int main(void)
+{
+char *chunks[9];
+int i;
+
+// Loop to allocate memory 8 times
+for (i = 0; i < 9; i++) {
+chunks[i] = malloc(0x100);
+if (chunks[i] == NULL) { // Check if malloc failed
+fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
+return 1;
+}
+printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
+}
+
+// Loop to free the allocated memory
+for (i = 0; i < 8; i++) {
+free(chunks[i]);
+}
+
+return 0;
+}
+```
+Observa cómo asignamos y liberamos 9 fragmentos del mismo tamaño para que **llenen la tcache** y el octavo se almacene en el bin no ordenado porque es **demasiado grande para el fastbin** y el noveno no se libera, por lo que el noveno y el octavo **no se fusionan con el chunk superior**.
+
+Compílalo y depúralo con un breakpoint en el opcode ret de la función main. luego con gef puedes ver el llenado del bin tcache y el único fragmento en el bin no ordenado:
+```bash
+gef➤ heap bins
+──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
+Tcachebins[idx=15, size=0x110, count=7] ← Chunk(addr=0xaaaaaaac1d10, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1c00, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1af0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac19e0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac18d0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac17c0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac12a0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
+Fastbins[idx=0, size=0x20] 0x00
+Fastbins[idx=1, size=0x30] 0x00
+Fastbins[idx=2, size=0x40] 0x00
+Fastbins[idx=3, size=0x50] 0x00
+Fastbins[idx=4, size=0x60] 0x00
+Fastbins[idx=5, size=0x70] 0x00
+Fastbins[idx=6, size=0x80] 0x00
+─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
+[+] unsorted_bins[0]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
+→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+[+] Found 1 chunks in unsorted bin.
+```
+
### Bins Pequeños
Los bins pequeños son más rápidos que los bins grandes pero más lentos que los bins rápidos.
-Cada bin de los 62 tendrá **fragmentos del mismo tamaño**: 16, 24, ... (con un tamaño máximo de 504 bytes en 32 bits y 1024 en 64 bits). Esto ayuda en la rapidez para encontrar el bin donde se debe asignar un espacio e insertar y eliminar entradas en estas listas.
+Cada bin de los 62 tendrá **trozos del mismo tamaño**: 16, 24, ... (con un tamaño máximo de 504 bytes en 32 bits y 1024 en 64 bits). Esto ayuda en la velocidad para encontrar el bin donde se debe asignar un espacio e insertar y eliminar entradas en estas listas.
-### Bins Grandes
+Así es como se calcula el tamaño del bin pequeño según el índice del bin:
-A diferencia de los bins pequeños, que gestionan fragmentos de tamaños fijos, cada **bin grande maneja un rango de tamaños de fragmentos**. Esto es más flexible, permitiendo al sistema acomodar **varios tamaños** sin necesidad de un bin separado para cada tamaño.
+* Tamaño más pequeño: 2\*4\*índice (por ejemplo, índice 5 -> 40)
+* Tamaño más grande: 2\*8\*índice (por ejemplo, índice 5 -> 80)
+```c
+// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
+#define NSMALLBINS 64
+#define SMALLBIN_WIDTH MALLOC_ALIGNMENT
+#define SMALLBIN_CORRECTION (MALLOC_ALIGNMENT > CHUNK_HDR_SZ)
+#define MIN_LARGE_SIZE ((NSMALLBINS - SMALLBIN_CORRECTION) * SMALLBIN_WIDTH)
+
+#define in_smallbin_range(sz) \
+((unsigned long) (sz) < (unsigned long) MIN_LARGE_SIZE)
+
+#define smallbin_index(sz) \
+((SMALLBIN_WIDTH == 16 ? (((unsigned) (sz)) >> 4) : (((unsigned) (sz)) >> 3))\
++ SMALLBIN_CORRECTION)
+```
+Función para elegir entre contenedores pequeños y grandes:
+```c
+#define bin_index(sz) \
+((in_smallbin_range (sz)) ? smallbin_index (sz) : largebin_index (sz))
+```
+Agregar un ejemplo de fragmento sin ordenar
+```c +#include
+
+
+#include
+
+int main(void)
+{
+char *chunks[10];
+int i;
+
+// Loop to allocate memory 8 times
+for (i = 0; i < 9; i++) {
+chunks[i] = malloc(0x100);
+if (chunks[i] == NULL) { // Check if malloc failed
+fprintf(stderr, "Memory allocation failed at iteration %d\n", i);
+return 1;
+}
+printf("Address of chunk %d: %p\n", i, (void *)chunks[i]);
+}
+
+// Loop to free the allocated memory
+for (i = 0; i < 8; i++) {
+free(chunks[i]);
+}
+
+chunks[9] = malloc(0x110);
+
+return 0;
+}
+```
+Observa cómo asignamos y liberamos 9 fragmentos del mismo tamaño para que **llenen la tcache** y el octavo se almacene en el bin no ordenado porque es **demasiado grande para el fastbin** y el noveno no se libera, por lo que el noveno y el octavo **no se fusionan con el fragmento superior**. Luego asignamos un fragmento más grande de 0x110, lo que hace que **el fragmento en el bin no ordenado pase al bin pequeño**.
+
+Compílalo y depúralo con un punto de interrupción en el opcode ret de la función principal. Luego, con gef, puedes ver el llenado del bin tcache y el único fragmento en el bin pequeño:
+```bash
+gef➤ heap bins
+──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
+Tcachebins[idx=15, size=0x110, count=7] ← Chunk(addr=0xaaaaaaac1d10, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1c00, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac1af0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac19e0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac18d0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac17c0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← Chunk(addr=0xaaaaaaac12a0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
+Fastbins[idx=0, size=0x20] 0x00
+Fastbins[idx=1, size=0x30] 0x00
+Fastbins[idx=2, size=0x40] 0x00
+Fastbins[idx=3, size=0x50] 0x00
+Fastbins[idx=4, size=0x60] 0x00
+Fastbins[idx=5, size=0x70] 0x00
+Fastbins[idx=6, size=0x80] 0x00
+─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
+[+] Found 0 chunks in unsorted bin.
+──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
+[+] small_bins[16]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
+→ Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+[+] Found 1 chunks in 1 small non-empty bins.
+```
+
+
+### Bins grandes
+
+A diferencia de los bins pequeños, que manejan fragmentos de tamaños fijos, cada **bin grande maneja un rango de tamaños de fragmentos**. Esto es más flexible, permitiendo que el sistema pueda acomodar **varios tamaños** sin necesidad de un bin separado para cada tamaño.
En un asignador de memoria, los bins grandes comienzan donde terminan los bins pequeños. Los rangos para los bins grandes crecen progresivamente, lo que significa que el primer bin podría cubrir fragmentos de 512 a 576 bytes, mientras que el siguiente cubre de 576 a 640 bytes. Este patrón continúa, con el bin más grande que contiene todos los fragmentos por encima de 1MB.
-Los bins grandes son más lentos de operar en comparación con los bins pequeños porque deben **ordenar y buscar a través de una lista de tamaños de fragmentos variables para encontrar el mejor ajuste** para una asignación. Cuando se inserta un fragmento en un bin grande, debe ser ordenado, y al asignar memoria, el sistema debe encontrar el fragmento adecuado. Este trabajo adicional los hace **más lentos**, pero como las asignaciones grandes son menos comunes que las pequeñas, es un compromiso aceptable.
+Los bins grandes son más lentos de operar en comparación con los bins pequeños porque deben **ordenar y buscar a través de una lista de tamaños de fragmentos variables para encontrar el mejor ajuste** para una asignación. Cuando un fragmento se inserta en un bin grande, debe ser ordenado, y cuando se asigna memoria, el sistema debe encontrar el fragmento adecuado. Este trabajo adicional los hace **más lentos**, pero dado que las asignaciones grandes son menos comunes que las pequeñas, es un compromiso aceptable.
Hay:
-* 32 bins de rango de 64B
-* 16 bins de rango de 512B
-* 8 bins de rango de 4096B
+* 32 bins de rango de 64B (colisionan con los bins pequeños)
+* 16 bins de rango de 512B (colisionan con los bins pequeños)
+* 8 bins de rango de 4096B (parte colisiona con los bins pequeños)
* 4 bins de rango de 32768B
* 2 bins de rango de 262144B
* 1 bin para tamaños restantes
-### Bin Desordenado
+Agregar un ejemplo de pequeño fragmento
+```c +#include
-El bin desordenado es una **caché rápida** utilizada por el administrador de montón para hacer que la asignación de memoria sea más rápida. Así es como funciona: Cuando un programa libera memoria, el administrador de montón no la coloca inmediatamente en un bin específico. En su lugar, primero intenta **fusionarla con cualquier fragmento libre vecino** para crear un bloque más grande de memoria libre. Luego, coloca este nuevo fragmento en un bin general llamado "bin desordenado".
+
-Los bins rápidos están diseñados para **acelerar la asignación de memoria para fragmentos pequeños** manteniendo fragmentos liberados recientemente en una estructura de acceso rápido. Estos bins utilizan un enfoque de Último en Entrar, Primero en Salir (LIFO), lo que significa que el **fragmento liberado más recientemente es el primero** en ser reutilizado cuando hay una nueva solicitud de asignación. Este comportamiento es ventajoso para la velocidad, ya que es más rápido insertar y eliminar desde la parte superior de una pila (LIFO) en comparación con una cola (FIFO).
+Código de tamaños de bins grandes
+```c +// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711 -Cuando un programa **solicita memoria**, el administrador de montón **verifica el bin desordenado** para ver si hay un fragmento de tamaño suficiente. Si encuentra uno, lo utiliza de inmediato. Si no encuentra un fragmento adecuado, mueve los fragmentos liberados a sus bins correspondientes, ya sea pequeños o grandes, según su tamaño. +#define largebin_index_32(sz) \ +(((((unsigned long) (sz)) >> 6) <= 38) ? 56 + (((unsigned long) (sz)) >> 6) :\ +((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\ +((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\ +((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\ +((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\ +126) -Por lo tanto, el bin desordenado es una forma de acelerar la asignación de memoria reutilizando rápidamente la memoria liberada recientemente y reduciendo la necesidad de búsquedas y fusiones que consumen tiempo. +#define largebin_index_32_big(sz) \ +(((((unsigned long) (sz)) >> 6) <= 45) ? 49 + (((unsigned long) (sz)) >> 6) :\ +((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\ +((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\ +((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\ +((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\ +126) -{% hint style="danger" %} -Ten en cuenta que incluso si los fragmentos son de diferentes categorías, si un fragmento disponible está colisionando con otro fragmento disponible (incluso si son de diferentes categorías), se fusionarán. -{% endhint %} +// XXX It remains to be seen whether it is good to keep the widths of +// XXX the buckets the same or whether it should be scaled by a factor +// XXX of two as well. +#define largebin_index_64(sz) \ +(((((unsigned long) (sz)) >> 6) <= 48) ? 48 + (((unsigned long) (sz)) >> 6) :\ +((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\ +((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\ +((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\ +((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\ +126) -### Bins Rápidos +#define largebin_index(sz) \ +(SIZE_SZ == 8 ? largebin_index_64 (sz) \ +: MALLOC_ALIGNMENT == 16 ? largebin_index_32_big (sz) \ +: largebin_index_32 (sz)) +``` +
-Además, **los bins rápidos utilizan listas enlazadas simples**, no dobles, lo que mejora aún más la velocidad. Dado que los fragmentos en los bins rápidos no se fusionan con vecinos, no es necesario una estructura compleja que permita la eliminación desde el medio. Una lista enlazada simple es más simple y rápida para estas operaciones.
+
+#include
-Básicamente, lo que sucede aquí es que el encabezado (el puntero al primer fragmento a verificar) siempre apunta al fragmento liberado más reciente de ese tamaño. Entonces:
+int main(void)
+{
+char *chunks[2];
-* Cuando se asigna un nuevo fragmento de ese tamaño, el encabezado apunta a un fragmento libre para usar. Como este fragmento libre apunta al siguiente fragmento a usar, esta dirección se almacena en el encabezado para que la próxima asignación sepa dónde obtener un fragmento disponible.
-* Cuando se libera un fragmento, el fragmento libre guardará la dirección al fragmento disponible actual y la dirección a este fragmento recién liberado se colocará en el encabezado.
+chunks[0] = malloc(0x1500);
+chunks[1] = malloc(0x1500);
+free(chunks[0]);
+chunks[0] = malloc(0x2000);
-{% hint style="danger" %}
-Los fragmentos en los bins rápidos no se establecen automáticamente como disponibles, por lo que se mantienen como fragmentos de bin rápido durante algún tiempo en lugar de poder fusionarse con otros fragmentos.
-{% endhint %}
+return 0;
+}
+```
+Dos grandes asignaciones se realizan, luego una se libera (poniéndola en el contenedor no ordenado) y se realiza una asignación más grande (moviendo la liberada del contenedor no ordenado al contenedor grande).
-### Bins Tcache (Caché por Hilo)
+Compílalo y depúralo con un punto de interrupción en el opcode ret de la función principal. Luego, con gef, puedes ver el llenado del contenedor tcache y el fragmento en el contenedor grande:
+```bash
+gef➤ heap bin
+──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
+All tcachebins are empty
+───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
+Fastbins[idx=0, size=0x20] 0x00
+Fastbins[idx=1, size=0x30] 0x00
+Fastbins[idx=2, size=0x40] 0x00
+Fastbins[idx=3, size=0x50] 0x00
+Fastbins[idx=4, size=0x60] 0x00
+Fastbins[idx=5, size=0x70] 0x00
+Fastbins[idx=6, size=0x80] 0x00
+─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
+[+] Found 0 chunks in unsorted bin.
+──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
+[+] Found 0 chunks in 0 small non-empty bins.
+──────────────────────────────────────────────────────────────────────── Large Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
+[+] large_bins[100]: fw=0xaaaaaaac1290, bk=0xaaaaaaac1290
+→ Chunk(addr=0xaaaaaaac12a0, size=0x1510, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+[+] Found 1 chunks in 1 large non-empty bins.
+```
+
-Aunque los hilos intentan tener su propio montón (ver [Arenas](bins-and-memory-allocations.md#arenas) y [Submontones](bins-and-memory-allocations.md#subheaps)), existe la posibilidad de que un proceso con muchos hilos (como un servidor web) **termine compartiendo el montón con otros hilos**. En este caso, la solución principal es el uso de **bloqueos**, que podrían **ralentizar significativamente los hilos**.
+### Trozo Superior
+```c
+// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
-Por lo tanto, un tcache es similar a un bin rápido por hilo en el sentido de que es una **lista enlazada simple** que no fusiona fragmentos. Cada hilo tiene **64 bins tcache enlazados individualmente**. Cada bin puede tener un máximo de [7 fragmentos del mismo tamaño](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) que van desde [24 a 1032B en sistemas de 64 bits y de 12 a 516B en sistemas de 32 bits](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
+/*
+Top
-Cuando un hilo **libera** un fragmento, **si no es demasiado grande** para ser asignado en el tcache y el bin tcache **no está lleno** (ya tiene 7 fragmentos), **se asignará allí**. Si no puede ir al tcache, deberá esperar a que el bloqueo del montón esté disponible para poder realizar la operación de liberación global.
+The top-most available chunk (i.e., the one bordering the end of
+available memory) is treated specially. It is never included in
+any bin, is used only if no other chunk is available, and is
+released back to the system if it is very large (see
+M_TRIM_THRESHOLD). Because top initially
+points to its own bin with initial zero size, thus forcing
+extension on the first malloc request, we avoid having any special
+code in malloc to check whether it even exists yet. But we still
+need to do so when getting memory from system, so we make
+initial_top treat the bin as a legal but unusable chunk during the
+interval between initialization and the first call to
+sysmalloc. (This is somewhat delicate, since it relies on
+the 2 preceding words to be zero during this interval as well.)
+*/
+
+/* Conveniently, the unsorted bin can be used as dummy top on first call */
+#define initial_top(M) (unsorted_chunks (M))
+```
+Básicamente, este es un fragmento que contiene toda la memoria heap disponible actualmente. Cuando se realiza un malloc, si no hay ningún fragmento libre disponible para usar, este fragmento superior reducirá su tamaño proporcionando el espacio necesario.\
+El puntero al Fragmento Superior se almacena en la estructura `malloc_state`.
+
+Además, al principio, es posible utilizar el fragmento no ordenado como el fragmento superior.
+
+Agregar un ejemplo de un gran fragmento
+```c +#include
+
+
+#include
+
+int main(void)
+{
+char *chunk;
+chunk = malloc(24);
+printf("Address of the chunk: %p\n", (void *)chunk);
+gets(chunk);
+return 0;
+}
+```
+Después de compilar y depurarlo con un punto de interrupción en el opcode ret de main, vi que el malloc devolvió la dirección: `0xaaaaaaac12a0` y estos son los fragmentos:
+```bash
+gef➤ heap chunks
+Chunk(addr=0xaaaaaaac1010, size=0x290, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+[0x0000aaaaaaac1010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................]
+Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+[0x0000aaaaaaac12a0 41 41 41 41 41 41 41 00 00 00 00 00 00 00 00 00 AAAAAAA.........]
+Chunk(addr=0xaaaaaaac12c0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+[0x0000aaaaaaac12c0 41 64 64 72 65 73 73 20 6f 66 20 74 68 65 20 63 Address of the c]
+Chunk(addr=0xaaaaaaac16d0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
+[0x0000aaaaaaac16d0 41 41 41 41 41 41 41 0a 00 00 00 00 00 00 00 00 AAAAAAA.........]
+Chunk(addr=0xaaaaaaac1ae0, size=0x20530, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← top chunk
+```
+Donde se puede ver que el fragmento superior está en la dirección `0xaaaaaaac1ae0`. Esto no es sorprendente porque el fragmento asignado más reciente estaba en `0xaaaaaaac12a0` con un tamaño de `0x410` y `0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0`.\
+También es posible ver la longitud del fragmento superior en su encabezado de fragmento:
+```bash
+gef➤ x/8wx 0xaaaaaaac1ae0 - 16
+0xaaaaaaac1ad0: 0x00000000 0x00000000 0x00020531 0x00000000
+0xaaaaaaac1ae0: 0x00000000 0x00000000 0x00000000 0x00000000
+```
+
+
+### Último Recordatorio
+
+Cuando se utiliza malloc y se divide un fragmento (de la lista no enlazada o del fragmento superior, por ejemplo), el fragmento creado a partir del resto del fragmento dividido se llama Último Recordatorio y su puntero se almacena en la estructura `malloc_state`.
-Cuando se **asigna un fragmento**, si hay un fragmento libre del tamaño necesario en el **tcache, se utilizará**, de lo contrario, deberá esperar a que el bloqueo del montón esté disponible para encontrar uno en los bins globales o crear uno nuevo.\
-También hay una optimización, en este caso, mientras tiene el bloqueo del montón, el hilo **llenará su tcache con fragmentos del montón (7) del tamaño solicitado**, por lo que en caso de que necesite más, los encontrará en el tcache.
## Flujo de Asignación
-{% hint style="success" %}
-(Esta explicación actual es de [https://heap-exploitation.dhavalkapil.com/diving\_into\_glibc\_heap/core\_functions](https://heap-exploitation.dhavalkapil.com/diving\_into\_glibc\_heap/core\_functions). TODO: Verificar la última versión y actualizarla)
-{% endhint %}
+Consulta:
-Las asignaciones se realizan finalmente con la función: `void * _int_malloc (mstate av, size_t bytes)` y siguen este orden:
+{% content-ref url="heap-memory-functions/malloc-and-sysmalloc.md" %}
+[malloc-and-sysmalloc.md](heap-memory-functions/malloc-and-sysmalloc.md)
+{% endcontent-ref %}
-1. Actualiza `bytes` para tener en cuenta **alineaciones**, etc.
-2. Verifica si `av` es **NULL** o no.
-3. En caso de ausencia de **área utilizable** (cuando `av` es NULL), llama a `sysmalloc` para obtener un fragmento usando mmap. Si tiene éxito, llama a `alloc_perturb`. Devuelve el puntero.
-4. Dependiendo del tamaño:
-* \[Adición a lo original] Usa tcache antes de verificar el siguiente fastbin.
-* \[Adición a lo original] Si no hay tcache pero se utiliza un bin diferente (ver paso posterior), intenta llenar tcache desde ese bin.
-* Si el tamaño cae en el rango de **fastbin**:
-1. Obtiene un índice en el array de fastbin para acceder a un bin apropiado según el tamaño solicitado.
-2. Elimina el primer fragmento en ese bin y hace que `víctima` apunte a él.
-3. Si `víctima` es NULL, pasa al siguiente caso (smallbin).
-4. Si `víctima` no es NULL, verifica el tamaño del fragmento para asegurarse de que pertenezca a ese bin en particular. De lo contrario, se lanza un error ("malloc(): corrupción de memoria (fast)").
-5. Llama a `alloc_perturb` y luego devuelve el puntero.
-* Si el tamaño cae en el rango de **smallbin**:
-1. Obtiene un índice en el array de smallbin para acceder a un bin apropiado según el tamaño solicitado.
-2. Si no hay fragmentos en este bin, pasa al siguiente caso. Esto se verifica comparando los punteros `bin` y `bin->bk`.
-3. `víctima` se iguala a `bin->bk` (el último fragmento en el bin). Si es NULL (ocurre durante la `inicialización`), llama a `malloc_consolidate` y salta este paso completo de verificación en diferentes bins.
-4. De lo contrario, cuando `víctima` no es NULL, verifica si `victim->bk->fd` y `víctima` son iguales o no. Si no son iguales, se lanza un error (`malloc(): lista doblemente enlazada de smallbin corrompida`).
-5. Establece el bit PREV\_INSUSE para el siguiente fragmento (en memoria, no en la lista doblemente enlazada) para `víctima`.
-6. Elimina este fragmento de la lista del bin.
-7. Establece el bit de arena apropiado para este fragmento según `av`.
-8. Llama a `alloc_perturb` y luego devuelve el puntero.
-* Si el tamaño no cae en el rango de smallbin:
-1. Obtiene un índice en el array de largebin para acceder a un bin apropiado según el tamaño solicitado.
-2. Verifica si `av` tiene fastchunks o no. Esto se hace verificando el `FASTCHUNKS_BIT` en `av->flags`. Si es así, llama a `malloc_consolidate` en `av`.
-5. Si aún no se ha devuelto ningún puntero, esto significa uno o más de los siguientes casos:
-1. El tamaño cae en el rango de 'fastbin' pero no hay fastchunk disponible.
-2. El tamaño cae en el rango de 'smallbin' pero no hay smallchunk disponible (llama a `malloc_consolidate` durante la inicialización).
-3. El tamaño cae en el rango de 'largebin'.
-6. A continuación, se verifican los **fragmentos no ordenados** y los fragmentos recorridos se colocan en bins. Este es el único lugar donde se colocan los fragmentos en bins. Itera el bin no ordenado desde la 'COLA'.
-1. `víctima` apunta al fragmento actual que se está considerando.
-2. Verifica si el tamaño del fragmento de `víctima` está dentro del rango mínimo (`2*SIZE_SZ`) y máximo (`av->system_mem`). De lo contrario, lanza un error (`malloc(): corrupción de memoria`).
-3. Si (el tamaño del fragmento solicitado cae en el rango de smallbin) y (`víctima` es el último fragmento restante) y (es el único fragmento en el bin no ordenado) y (el tamaño de los fragmentos >= el solicitado): **Divide el fragmento en 2 fragmentos**:
-* El primer fragmento coincide con el tamaño solicitado y se devuelve.
-* El fragmento restante se convierte en el nuevo último fragmento restante. Se inserta de nuevo en el bin no ordenado.
-1. Establece los campos `chunk_size` y `chunk_prev_size` apropiadamente para ambos fragmentos.
-2. Se devuelve el primer fragmento después de llamar a `alloc_perturb`.
-3. Si la condición anterior es falsa, el control llega aquí. Elimina `víctima` del bin no ordenado. Si el tamaño de `víctima` coincide exactamente con el tamaño solicitado, devuelve este fragmento después de llamar a `alloc_perturb`.
-4. Si el tamaño de `víctima` cae en el rango de smallbin, agrega el fragmento en el smallbin apropiado en la `CABEZA`.
-5. De lo contrario, inserta en el largebin apropiado manteniendo el orden ordenado:
-6. Primero verifica el último fragmento (más pequeño). Si `víctima` es más pequeña que el último fragmento, lo inserta al final.
-7. De lo contrario, bucle para encontrar un fragmento con un tamaño >= al tamaño de `víctima`. Si el tamaño es exactamente el mismo, siempre se inserta en la segunda posición.
-8. Repite este paso completo un máximo de `MAX_ITERS` (10000) veces o hasta que se agoten todos los fragmentos en el bin no ordenado.
-7. Después de verificar los fragmentos no ordenados, verifica si el tamaño solicitado no cae en el rango de smallbin, si es así, verifica los **largebins**.
-1. Obtiene un índice en el array de largebin para acceder a un bin apropiado según el tamaño solicitado.
-2. Si el tamaño del fragmento más grande (el primer fragmento en el bin) es mayor que el tamaño solicitado:
-1. Itera desde la 'COLA' para encontrar un fragmento (`víctima`) con el tamaño más pequeño >= al tamaño solicitado.
-2. Llama a `unlink` para eliminar el fragmento `víctima` del bin.
-3. Calcula `remainder_size` para el fragmento de `víctima` (esto será el tamaño del fragmento de `víctima` - tamaño solicitado).
-4. Si este `remainder_size` >= `MINSIZE` (el tamaño mínimo del fragmento incluyendo los encabezados), divide el fragmento en dos fragmentos. De lo contrario, se devolverá todo el fragmento de `víctima`. Inserta el fragmento restante en el bin no ordenado (en el extremo 'COLA'). Se realiza una verificación en el bin no ordenado si `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`. Se lanza un error de lo contrario ("malloc(): fragmentos no ordenados corruptos").
-5. Devuelve el fragmento de `víctima` después de llamar a `alloc_perturb`.
-8. Hasta ahora, hemos verificado el bin no ordenado y también el respectivo bin fast, small o large. Tenga en cuenta que se verificó un solo bin (fast o small) usando el tamaño **exacto** del fragmento solicitado. Repita los siguientes pasos hasta que se agoten todos los bins:
-1. Se incrementa el índice en el array de bin para verificar el siguiente bin.
-2. Usa el mapa `av->binmap` para saltar los bins que están vacíos.
-3. `víctima` apunta a la 'COLA' del bin actual.
-4. El uso del binmap asegura que si se salta un bin (en el paso 2 anterior), definitivamente está vacío. Sin embargo, no garantiza que se salten todos los bins vacíos. Verifica si la víctima está vacía o no. Si está vacía, nuevamente salta el bin y repite el proceso anterior (o 'continúa' este bucle) hasta llegar a un bin no vacío.
-5. Divide el fragmento (`víctima` apunta al último fragmento de un bin no vacío) en dos fragmentos. Inserta el fragmento restante en el bin no ordenado (en el extremo 'COLA'). Se realiza una verificación en el bin no ordenado si `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`. Se lanza un error de lo contrario ("malloc(): fragmentos no ordenados corruptos 2").
-6. Devuelve el fragmento de `víctima` después de llamar a `alloc_perturb`.
-9. Si aún no se encuentra un bin vacío, se utilizará el fragmento 'top' para atender la solicitud:
-1. `víctima` apunta a `av->top`.
-2. Si el tamaño del fragmento 'top' >= 'tamaño solicitado' + `MINSIZE`, divídalo en dos fragmentos. En este caso, el fragmento restante se convierte en el nuevo fragmento 'top' y el otro fragmento se devuelve al usuario después de llamar a `alloc_perturb`.
-3. Verifica si `av` tiene fastchunks o no. Esto se hace verificando el `FASTCHUNKS_BIT` en `av->flags`. Si es así, llama a `malloc_consolidate` en `av`. Vuelve al paso 6 (donde verificamos el bin no ordenado).
-4. Si `av` no tiene fastchunks, llama a `sysmalloc` y devuelve el puntero obtenido después de llamar a `alloc_perturb`.
-## Flujo Libre
+## Flujo de Liberación
-{% hint style="success" %}
-(Esta explicación actual es de [https://heap-exploitation.dhavalkapil.com/diving\_into\_glibc\_heap/core\_functions](https://heap-exploitation.dhavalkapil.com/diving\_into\_glibc\_heap/core\_functions). TODO: Verificar la última versión y actualizarla)
-{% endhint %}
+Consulta:
-La función final que libera fragmentos de memoria es `_int_free (mstate av, mchunkptr p, int have_lock)`:
+{% content-ref url="heap-memory-functions/free.md" %}
+[free.md](heap-memory-functions/free.md)
+{% endcontent-ref %}
-1. Verificar si `p` está antes de `p + chunksize(p)` en la memoria (para evitar desbordamientos). De lo contrario, se lanza un error (`free(): invalid pointer`).
-2. Verificar si el fragmento tiene al menos el tamaño `MINSIZE` o es un múltiplo de `MALLOC_ALIGNMENT`. De lo contrario, se lanza un error (`free(): invalid size`).
-3. Si el tamaño del fragmento está en la lista de fastbins:
-1. Verificar si el tamaño del siguiente fragmento está entre el tamaño mínimo y máximo (`av->system_mem`), lanzar un error (`free(): invalid next size (fast)`) de lo contrario.
-2. Llamar a `free_perturb` en el fragmento.
-3. Establecer `FASTCHUNKS_BIT` para `av`.
-4. Obtener el índice en el array de fastbins según el tamaño del fragmento.
-5. Verificar si la parte superior del bin no es el fragmento que vamos a agregar. De lo contrario, lanzar un error (`double free or corruption (fasttop)`).
-6. Verificar si el tamaño del fragmento de fastbin en la parte superior es el mismo que el fragmento que estamos agregando. De lo contrario, lanzar un error (`invalid fastbin entry (free)`).
-7. Insertar el fragmento en la parte superior de la lista de fastbins y retornar.
-4. Si el fragmento no está asignado dinámicamente:
-1. Verificar si el fragmento es el fragmento superior o no. Si es así, se lanza un error (`double free or corruption (top)`).
-2. Verificar si el siguiente fragmento (por memoria) está dentro de los límites del área. Si no, se lanza un error (`double free or corruption (out)`).
-3. Verificar si el bit previo en uso del siguiente fragmento (por memoria) está marcado o no. Si no, se lanza un error (`double free or corruption (!prev)`).
-4. Verificar si el tamaño del siguiente fragmento está entre el tamaño mínimo y máximo (`av->system_mem`). Si no, se lanza un error (`free(): invalid next size (normal)`).
-5. Llamar a `free_perturb` en el fragmento.
-6. Si el fragmento previo (por memoria) no está en uso, llamar a `unlink` en el fragmento previo.
-7. Si el siguiente fragmento (por memoria) no es el fragmento superior:
-1. Si el siguiente fragmento no está en uso, llamar a `unlink` en el siguiente fragmento.
-2. Fusionar el fragmento con el anterior, siguiente (por memoria), si alguno está libre y agregarlo al principio del bin desordenado. Antes de insertar, verificar si `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)` o no. Si no, se lanza un error ("free(): corrupted unsorted chunks").
-8. Si el siguiente fragmento (por memoria) era un fragmento superior, fusionar los fragmentos adecuadamente en un único fragmento superior.
-5. Si el fragmento estaba asignado dinámicamente, llamar a `munmap_chunk`.
+## Verificaciones de Seguridad de Funciones de Montón
-## Verificaciones de Seguridad de Funciones de Heap
+Verifica las verificaciones de seguridad realizadas por funciones ampliamente utilizadas en el montón en:
-Verifique las verificaciones de seguridad realizadas por funciones ampliamente utilizadas en el heap en:
-
-{% content-ref url="heap-functions-security-checks.md" %}
-[heap-functions-security-checks.md](heap-functions-security-checks.md)
+{% content-ref url="heap-memory-functions/heap-functions-security-checks.md" %}
+[heap-functions-security-checks.md](heap-memory-functions/heap-functions-security-checks.md)
{% endcontent-ref %}
## Referencias
@@ -194,15 +601,16 @@ Verifique las verificaciones de seguridad realizadas por funciones ampliamente u
* [https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/](https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/)
* [https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/](https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/)
* [https://heap-exploitation.dhavalkapil.com/diving\_into\_glibc\_heap/core\_functions](https://heap-exploitation.dhavalkapil.com/diving\_into\_glibc\_heap/core\_functions)
+* [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/implementation/tcache/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/implementation/tcache/)
Observa el ejemplo del Fragmento Superior
+```c +#include
-
@@ -21,7 +21,7 @@ Un desbordamiento de montón es como un [**desbordamiento de pila**](../stack-ov
En los desbordamientos de pila sabemos que algunos registros como el puntero de instrucción o el marco de pila van a ser restaurados desde la pila y podría ser posible abusar de esto. En el caso de los desbordamientos de montón, **no hay ninguna información sensible almacenada por defecto** en el fragmento de montón que puede ser desbordado. Sin embargo, podría ser información sensible o punteros, por lo que la **críticidad** de esta vulnerabilidad **depende** de **qué datos podrían ser sobrescritos** y de cómo un atacante podría abusar de esto.
{% hint style="success" %}
-Para encontrar los desbordamientos de montón puedes usar los mismos patrones que en los [**desbordamientos de pila**](../stack-overflow/#finding-stack-overflows-offsets).
+Para encontrar los desbordamientos de desbordamiento puedes usar los mismos patrones que en los [**desbordamientos de pila**](../stack-overflow/#finding-stack-overflows-offsets).
{% endhint %}
### Desbordamientos de Pila vs Desbordamientos de Montón
@@ -30,23 +30,31 @@ En los desbordamientos de pila, la disposición y los datos que van a estar pres
Sin embargo, en el caso de un desbordamiento de montón, debido a que la memoria utilizada no es lineal sino que **los fragmentos asignados suelen estar en posiciones separadas de la memoria** (no uno al lado del otro) debido a **contenedores y zonas** que separan las asignaciones por tamaño y porque **la memoria previamente liberada se utiliza** antes de asignar nuevos fragmentos. Es **complicado saber el objeto que va a estar colisionando con el vulnerable** a un desbordamiento de montón. Por lo tanto, cuando se encuentra un desbordamiento de montón, es necesario encontrar una **forma confiable de hacer que el objeto deseado esté a continuación en la memoria** del que puede ser desbordado.
-Una de las técnicas utilizadas para esto es el **Aseo de Montón** que se utiliza, por ejemplo, [**en este post**](https://azeria-labs.com/grooming-the-ios-kernel-heap/). En el post se explica cómo en el núcleo de iOS cuando una zona se queda sin memoria para almacenar fragmentos de memoria, la expande en una página de kernel, y esta página se divide en fragmentos de los tamaños esperados que se utilizarían en orden (hasta la versión 9.2 de iOS, luego estos fragmentos se utilizan de manera aleatoria para dificultar la explotación de estos ataques).
+Una de las técnicas utilizadas para esto es el **Aseo de Montón** que se utiliza, por ejemplo, [**en este post**](https://azeria-labs.com/grooming-the-ios-kernel-heap/). En el post se explica cómo en el núcleo de iOS, cuando una zona se queda sin memoria para almacenar fragmentos de memoria, la expande en una página de núcleo, y esta página se divide en fragmentos de los tamaños esperados que se utilizarían en orden (hasta la versión 9.2 de iOS, luego estos fragmentos se utilizan de manera aleatoria para dificultar la explotación de estos ataques).
-Por lo tanto, en el post anterior donde ocurre un desbordamiento de montón, para forzar que el objeto desbordado esté colisionando con un orden víctima, se fuerzan varios **`kallocs` por varios hilos para intentar asegurar que todos los fragmentos libres estén llenos y que se cree una nueva página**.
+Por lo tanto, en el post anterior donde ocurre un desbordamiento de montón, para forzar que el objeto desbordado esté colisionando con un orden víctima, varios **`kallocs` son forzados por varios hilos para intentar asegurar que todos los fragmentos libres estén llenos y que se cree una nueva página**.
-Para forzar este llenado con objetos de un tamaño específico, la **asignación fuera de línea asociada con un puerto mach de iOS** es un candidato ideal. Al diseñar el tamaño del mensaje, es posible especificar exactamente el tamaño de la asignación de `kalloc` y cuando se destruye el puerto mach correspondiente, la asignación correspondiente se liberará inmediatamente de vuelta a `kfree`.
+Para forzar este llenado con objetos de un tamaño específico, la **asignación fuera de línea asociada con un puerto mach iOS** es un candidato ideal. Al diseñar el tamaño del mensaje, es posible especificar exactamente el tamaño de la asignación de `kalloc` y cuando se destruye el puerto mach correspondiente, la asignación correspondiente se liberará inmediatamente a `kfree`.
Luego, algunos de estos marcadores de posición pueden ser **liberados**. La lista de liberación de **`kalloc.4096` libera elementos en orden de último en entrar, primero en salir**, lo que básicamente significa que si algunos marcadores de posición son liberados y el exploit intenta asignar varios objetos víctimas mientras intenta asignar el objeto vulnerable al desbordamiento, es probable que este objeto sea seguido por un objeto víctima.
-## Ejemplo ARM64
+### Ejemplo libc
-En la página [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) puedes encontrar un ejemplo de desbordamiento de montón donde un comando que va a ser ejecutado se almacena en el siguiente fragmento desde el fragmento desbordado. Por lo tanto, es posible modificar el comando ejecutado sobrescribiéndolo con un exploit sencillo como:
+[**En esta página**](https://guyinatuxedo.github.io/27-edit\_free\_chunk/heap\_consolidation\_explanation/index.html) es posible encontrar una emulación básica de desbordamiento de montón que muestra cómo sobrescribir el bit previo en uso del siguiente fragmento y la posición del tamaño previo es posible **consolidar un fragmento utilizado** (haciéndolo creer que no está en uso) y **luego asignarlo nuevamente** pudiendo sobrescribir datos que se están utilizando en un puntero diferente también.
+
+Otro ejemplo de [**protostar heap 0**](https://guyinatuxedo.github.io/24-heap\_overflow/protostar\_heap0/index.html) muestra un ejemplo muy básico de un CTF donde un **desbordamiento de montón** puede ser abusado para llamar a la función ganadora y **obtener la bandera**.
+
+En el ejemplo [**protostar heap 1**](https://guyinatuxedo.github.io/24-heap\_overflow/protostar\_heap1/index.html) es posible ver cómo abusando de un desbordamiento de búfer es posible **sobrescribir en un fragmento cercano una dirección** donde se va a escribir **datos arbitrarios del usuario**.
+
+### Ejemplo ARM64
+
+En la página [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) puedes encontrar un ejemplo de desbordamiento de montón donde un comando que va a ser ejecutado se almacena en el siguiente fragmento al fragmento desbordado. Por lo tanto, es posible modificar el comando ejecutado sobrescribiéndolo con un exploit sencillo como:
```bash
python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
```
Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!
+Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks: * Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)! -* Obtén la [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com) +* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com) * Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud). diff --git a/binary-exploitation/heap/heap-overflow.md b/binary-exploitation/heap/heap-overflow.md index a298a34cf..0d3b62b3e 100644 --- a/binary-exploitation/heap/heap-overflow.md +++ b/binary-exploitation/heap/heap-overflow.md @@ -6,11 +6,11 @@ Otras formas de apoyar a HackTricks: -* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)! +* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)! * Obtén el [**swag oficial de PEASS & HackTricks**](https://peass.creator-spring.com) * Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** -* **Comparte tus trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github. +* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
-
@@ -89,11 +89,11 @@ return 0;
```
-* El ataque no funciona si se utilizan tcaches
+* El ataque no funciona si se utilizan tcaches (después de la versión 2.26)
### Objetivo
-* Modificar un puntero a un fragmento en la pila para que apunte a la pila y sea posible alterar el contenido de la pila escribiendo en el fragmento
+* Modificar un puntero a un fragmento en la pila para que apunte a la pila, de modo que sea posible alterar el contenido de la pila escribiendo en el fragmento
### Requisitos
@@ -116,22 +116,27 @@ return 0;
* `fake_chunk->bk->fd` = `fake_chunk->fd`
* Anteriormente se hizo que `fake_chunk->fd->bk` y `fake_chunk->fd->bk` apunten al mismo lugar (la ubicación en la pila donde se almacenaba `fragmento1`, por lo que era una lista enlazada válida). Como **ambos apuntan al mismo lugar**, solo el último (`fake_chunk->bk->fd = fake_chunk->fd`) tendrá **efecto**.
* Esto **sobrescribirá el puntero al fragmento1 en la pila a la dirección (o bytes) almacenados 3 direcciones antes en la pila**.
-* Por lo tanto, si un atacante pudiera controlar nuevamente el contenido del fragmento1, podrá **escribir dentro de la pila**, pudiendo potencialmente sobrescribir la dirección de retorno saltando el canary y modificar los valores y puntos de las variables locales. Incluso modificando nuevamente la dirección del fragmento1 almacenada en la pila a una ubicación diferente donde si el atacante pudiera controlar nuevamente el contenido del fragmento1, podrá escribir en cualquier lugar.
+* Por lo tanto, si un atacante pudiera controlar nuevamente el contenido del fragmento1, podrá **escribir dentro de la pila**, pudiendo potencialmente sobrescribir la dirección de retorno saltando el canary y modificar los valores y puntos de las variables locales. Incluso modificando nuevamente la dirección del fragmento1 almacenada en la pila a una ubicación diferente donde, si el atacante pudiera controlar nuevamente el contenido del fragmento1, podrá escribir en cualquier lugar.
+* Tenga en cuenta que esto fue posible porque las **direcciones se almacenan en la pila**. El riesgo y la explotación pueden depender de **dónde se almacenan las direcciones del fragmento falso**.
Aprende hacking en AWS de cero a héroe con htARTE (Experto en Equipo Rojo de AWS de HackTricks)!
+Aprende hacking en AWS de cero a héroe con htARTE (Experto en Red Team de AWS de HackTricks)!
Otras formas de apoyar a HackTricks: diff --git a/binary-exploitation/heap/unlink-attack.md b/binary-exploitation/heap/unlink-attack.md index 5f15972eb..0dfe681e0 100644 --- a/binary-exploitation/heap/unlink-attack.md +++ b/binary-exploitation/heap/unlink-attack.md @@ -6,11 +6,11 @@ Otras formas de apoyar a HackTricks: -* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)! -* Obtén la [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com) +* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)! +* Obtén [**productos oficiales de PEASS & HackTricks**](https://peass.creator-spring.com) * Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** -* **Comparte tus trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github. +* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)..png)
https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit
-