vibecoded 퍼저가 FFmpeg VPK 디먹서의 0 나누기 DoS 크래시 보고

LLM으로 열린 버그 사냥을 돌리는 건 꽤 유용하다고 봄. 사람 개발자 시간을 오래 쓰고도 못 찾을 일을, 에이전트가 헛수고해도 되는 비용으로 찾을 수 있으니까.

LLM은 자체 루프 알고리즘을 만드는 것보다 빠르고, 결과물이 나올 확률도 꽤 높음. 다만 나온 결과를 검토하고 정리해서 다른 데를 망가뜨리지 않게 하는 일이 더 어려움.

AI 사용법은 속도와 품질로 나뉜다고 봄. 빨리 만들 때는 AI가 작업하고 내가 검토하고, 품질이 필요할 때는 내가 작성한 코드를 AI에게 리뷰시키는 식임.

토큰도 공짜는 아닌데, 아무것도 못 찾아도 손해가 없다는 말은 과장임.

LLM이 코드를 망가뜨린 사례 얘기인 줄 알았는데, 이건 vibecoded fuzzer가 기존 버그를 찾은 이야기임.

문제 코드는 인간이 7년 전에 커밋한 거임. LLM이 과거로 가서 버그를 심은 건 아님.

패치를 보내라는 말에는 동의함.

이미 패치도 보냈다고 함.

퍼저가 잘못된 입력 파일을 만드는 건 쉬운 축임. 유효한 입력을 만들어 깊은 호출 경로까지 들어간 뒤 버그를 찾는 쪽이 어려움.

모든 / 연산을 0 나누기 후보로 표시하면 안 되나 싶긴 함. 명시적으로 검사하지 않았거나 컴파일러가 보장하지 않으면 개발자의 확신만 믿기 어렵잖아.

정적 분석으로 전부 경고하면 거짓 양성이 너무 많아서 아무도 경고를 안 믿게 됨. 0이 아닌 상수로 나누는 경우 같은 건 제외해야 하고, 실제로 도달 가능한 입력을 찾는 게 퍼저의 역할임.

0이 될 수 없는 숫자 타입이나 refinement type이 있으면 좋겠음. F*는 나누는 쪽에 divisor <> 0이라는 조건을 타입으로 적을 수 있음.

컴파일러가 최적화에 쓰는 범위 분석을 재사용해, 정적으로 증명되는 0 나누기나 오버플로를 잡으면 좋겠음.

AI가 퍼저를 썼다는 부분보다, 싼 랜덤 하니스가 오래된 파서의 고전적 버그를 아직 잡는다는 점이 더 흥미로움. 코퍼스는 보관하고 과장은 버리면 됨.

FFmpeg를 써야 한다면 예상하는 파일 형식만 허용 목록으로 빌드해야 한다고 봄. 쓰지 않을 포맷까지 전부 넣는 방식은 피해야 함.

이건 FFmpeg 자체의 실제 파일 경로 버그라기보다 커스텀 AVIO가 서로 다른 데이터를 주면 크래시를 낼 수 있다는 시연이라는 반론도 있음. VPK 모듈 자체는 기존 모듈이고, 실제 파일에서는 일어나지 않을 거라는 주장임.