La semana pasada, la cuenta @FFmpeg empezó a burlarse de los investigadores de seguridad. Una tontería, pues ignora la asimetría entre su superficie de ataque y la nuestra. Como ejercicio, encontré un desbordamiento de búfer basado en pila en un software que él escribió. Me llevó unos 20 minutos encontrarlo. Hilo 🧵(1/5)
Primero, me di cuenta de que la cuenta de FFMpeg no está controlada por un desarrollador activo de FFMpeg, sino aparentemente por varias personas, una de ellas llamada Keiran. Es extraño, pero no es importante. El usuario keirank de GitHub tiene muy pocos commits, y ninguno en FFMPEG, sino en Upipe, un software de procesamiento de vídeo de su empresa. Revisemos su commit más reciente: "Validar num_delta_pocs para evitar un desbordamiento de pila". (2/5)
@FFmpeg De hecho, @FFmpeg escribió una validación, pero solo comprueba un índice a pesar de trabajar con matrices bidimensionales de dimensiones variables. Esto no puede ser correcto. Como no tuve tiempo de verificarlo, le encargué a un experto en LLM que "encontrara errores críticos en el código". GLM 4.6 encontró muchos (3/5)
Cada vez que se calcula un fotograma predictor, se incrementa la matriz de imágenes de referencia, pero esto no se tiene en cuenta en las validaciones. Desbordamiento (lectura excesiva). Así que tenemos una forma de sobreleer hasta 64 bytes de la pila (64 es la cantidad máxima de marcos de referencia). ¿Pero podemos escribir en la pila? Le pedí al LLM que escribiera un fuzzer de framer h265; es muy complejo, sin embargo, lo hace de una sola vez (4/5).
@FFmpeg Ahora tenemos un desbordamiento de búfer basado en pila de lectura/escritura. Se acabó. El fuzzer y la explicación completa sgithub.com/ortegaalfredo/…i GitHub: https://t.co/7m0i6Dmvud
