지난주 @FFmpeg 계정에서 보안 연구원들을 조롱하기 시작했습니다. 그들의 공격 영역과 우리의 공격 영역이 서로 다르다는 사실을 무시하는 어리석은 행동입니다. 그래서 연습 삼아 그가 만든 소프트웨어에서 스택 기반 버퍼 오버플로우를 찾아냈어요. 찾는 데 20분 정도 걸렸어요. 스레드 🧵(1/5)
첫째, FFMpeg 계정은 FFMpeg의 활동적인 개발자가 관리하는 것이 아니라, 여러 사람이 관리하는 것으로 보이는데, 그중 한 명은 Keiran이라는 사람입니다. 이상하지만 중요한 건 아닙니다. keirank github 사용자는 커밋이 거의 없고, FFMPEG에 대한 커밋도 없지만, 그의 회사에서 만든 비디오 처리 소프트웨어인 Upipe에 대해서는 커밋을 한 적이 없습니다. 그럼 그의 가장 최근 커밋인 "스택 충돌을 방지하기 위해 num_delta_pocs 검증"을 확인해 보겠습니다. (2/5)
@FFmpeg 실제로 @FFmpeg는 검증 기능을 작성했지만, 다양한 차원의 2차원 배열을 사용함에도 불구하고 하나의 인덱스만 확인합니다. 이건 옳을 리가 없습니다. 확인할 시간이 없어서 LLM에게 "코드에서 중요한 버그를 찾아라"라고 지시했습니다. GLM 4.6에서 많은(3/5) 발견
예측 프레임이 계산될 때마다 참조 PIC 배열이 증가하지만, 이는 검증에서 고려되지 않습니다. 오버플로(과도하게 읽힘). 따라서 스택에서 최대 64바이트를 읽을 수 있는 방법이 있습니다(64는 참조 프레임의 최대 양입니다). 하지만 스택에 쓸 수 있을까요? LLM에 h.265 프레이머 퍼저를 만들어 달라고 부탁했는데, 아주 복잡하긴 하지만 원샷으로 처리해 줍니다. (4/5)
@FFmpeg 이제 스택 기반 읽기/쓰기 버퍼 오버플로가 가능해졌습니다. 게임 오버입니다. Fuzzer와 전체 설명은 내 github에서 확인할 수 있습니다. https://t.co/7m0i6Dmvud
