FFmpeg에서 21바이트 입력으로 SIGFPE를 유발하는 제로 나눗셈 버그 발견

AI가 소프트웨어의 품질을 어떻게 높이고 낮출지 흥미롭습니다. AI 에이전트에게 막연한 버그 사냥을 시키는 것은 매우 쉽고, 시간과 노력을 많이 낭비한 끝에 아무것도 찾지 못해도 큰 문제가 아닙니다. 급여를 받는 인간 개발자에게는 시간이 훨씬 더 중요합니다.

이 버그의 구체적인 내용과 그것이 유용한 벡터인지 여부와는 별개로, 이것은 전혀 놀라운 일이 아닙니다.

LLM에 대한 나의 현재 의견은, 피로가 없고 인간에게 공개적으로 알려진 모든 주제에 대해 거의 완전한 지식을 가지고 있으며, 유명하게 복잡한 C 코드베이스에서 버그를 찾기 위한 하네스를 코드로 작성할 수 있다는 점이 인턴 수준의 일이고 뉴스거리가 거의 아니라는 점에서 초인적이라는 것입니다.

똑똑한 지망생 블랙햇들은 다음으로 tmux를 표적으로 삼을 것입니다. 가벼운 LLM 탈옥, 가벼운 공급망 공격(웹 검색 결과), 그리고 특정 환경 내에서의 LPE(로컬 권한 상승)를 통해 말이죠. 이러한 것들은 이전에는 특별히 유용하지 않았지만, 에이전트가 몇 시간 동안 자동 모드로 실행되면 매우 귀중한 발판이 됩니다. tmux 코드의 품질은 잘 모르겠지만, C로 작성되었고 매우 복잡하며 이러한 유형의 위협을 방어하도록 설계되지 않았다는 것은 알고 있습니다.

이것은 FFmpeg의 실제 버그가 아닙니다. 사용자 정의 AVIO 모듈을 제어하면 잘못된 데이터를 제공하여 FFmpeg를 충돌시킬 수 있다는 것을 보여주는 것입니다.

퍼저(바이브코딩된 것이든 아니든)가 강력할 수 있다는 데 의심의 여지가 없지만, 모든 "/"를 잠재적인 0으로 나누기 오류로 표시할 수는 없나요?

가끔 개발자들은 일부 변수가 0이 아닐 것이라고 "안다"고 생각하지만, 명시적으로 확인되거나 컴파일러에 의해 확인되지 않는 한 그렇게 신뢰해서는 안 됩니다.

이런 식으로 대충 만든 퍼저가 실제로 ffmpeg에서 버그를 찾았다는 것이 꽤 멋지다고 생각합니다.

재미있는 점은, 제가 gStreamer 개발자의 어떤 것에 부딪히고 있다는 것을 알지만 Fable이 화를 내며 반응한다는 것입니다. 문제가 어디에 숨어 있을지에 대한 느슨한 아이디어만 있습니다.

다음 주에 사이버에 지원할 예정이고 비슷한 것을 찾을 것 같습니다.

지금은 그냥 짜증날 뿐이고 OpenAI 사이버가 접근하기 훨씬 쉬웠던 것에 감사합니다.

제가 놓치고 있는 것이 있나요? 누가 신경 쓰나요? 이것은 보안 문제가 아니라 잘못된 데이터에 대한 악용할 수 없는 충돌일 뿐입니다.