Na semana passada, a conta @FFmpeg começou a provocar pesquisadores de segurança. Uma atitude tola, pois ignora a assimetria entre a superfície de ataque deles e a nossa. Como exercício, encontrei um estouro de buffer baseado em pilha em um software que ele escreveu. Levei cerca de 20 minutos para encontrá-lo. Tópico 🧵(1/5)
Primeiro, notei que a conta do FFMpeg não é controlada por um desenvolvedor ativo do FFMpeg, mas aparentemente por várias pessoas, uma delas chamada Keiran. Estranho, mas não é importante. O usuário keirank do GitHub tem pouquíssimos commits, e nenhum no FFMPEG, mas sim no Upipe, um software de processamento de vídeo de sua empresa. Então vamos verificar seu commit mais recente "Validar num_delta_pocs para evitar um estouro de pilha". (2/5)
@FFmpeg De fato, @FFmpeg escreveu uma validação, mas ela verifica apenas um índice, apesar de trabalhar com matrizes bidimensionais de dimensões variáveis. Isso não pode estar certo. Como não tive tempo de verificar, instruí um gerente de projeto a "encontrar erros críticos no código". GLM 4.6 encontrou muitos (3/5)
Cada vez que um quadro preditor é calculado, ele aumenta o array de imagens de referência, mas isso não é levado em consideração nas validações. Overflow (leitura excessiva). Assim, temos uma maneira de ler até 64 bytes da pilha (sendo 64 o número máximo de quadros de referência). Mas podemos escrever na pilha? Eu pedi ao LLM para escrever um fuzzer de framer h265, é muito complexo, no entanto, ele faz isso em uma única execução (4/5)
@FFmpeg Então agora temos estouro de buffer baseado em pilha de leitura/escrita. Fim de jogo. O fuzzer e a explicação completa podem github.com/ortegaalfredo/…GitHub: https://t.co/7m0i6Dmvud
