보안 버그의 '소문'만으로 익스플로잇을 찾는 시대가 왔다
Just the rumour of a bug is enough to find an exploit these days
OCaml의 HTTP 라이브러리 cohttp 6.3.0에서 경로 탐색(path traversal) 취약점을 수정한 Anil Madhavapeddy가, 공개된 PR을 연 지 불과 몇 분 만에 자신의 웹 서버 로그에서 동일한 버그 패턴을 이용한 프로브를 발견했다고 전한다. 그는 자신의 에이전트로 버그의 대략적인 내용만 알면 1분 안에 익스플로잇을 만들 수 있다는 사실도 확인했다. 이 글은 LLM 기반 자동 익스플로잇 생성이 보안 공개 절차를 무력화하고 있음을 지적하며, 보안 엠바고가 더 이상 효과적이지 않다고 주장한다. 대안으로 비공개 패치 개발, 지속적 배포, 프로토콜 계층의 가상 패치, OSS 유지보수자를 위한 웹오브트러스트 등을 제안한다.
오늘날 에이전트에게 필요한 것은 단지 탐색할 대략적인 방향뿐이며, 그 방향만 있으면 스스로 조사하여 익스플로잇을 찾아낼 수 있다.
HN 토론
102- nickcw
이것은 현재 오픈소스 메인테이너로서의 제 삶을 그대로 묘사하고 있습니다!
rclone 프로젝트의 처음 10년 동안 우리는 GitHub를 통해 약 20건의 보안 공개를 받았습니다. 지난 한 달 동안 40건 이상을 처리해야 했습니다! 그건 제 시간을 엄청나게 많이 잡아먹었고, AI 도구를 사용해 분류하고 검토할 수정안을 만드는 데도 그랬습니다.
그 보안 공개의 적중률은 꽤 좋습니다 - 약 75%는 뭔가 살펴봐야 할 알맹이가 있습니다. rclone의 설정이 점점 더 이상해져서 언젠가는 그런 것들이 줄어들기를 바라고 있습니다.
저는 그냥 수정 사항을 바로 master에 병합해서 제 삶을 편하게 할까도 고려했습니다. 수십 개의 독립적인 보안 수정을 브랜치에 보관하고 포인트 릴리스에서 병합하고 충돌이 너무 많지 않기를 바라는 대신에요. 하지만 지금은 그 프로세스를 유지하기로 결정했습니다.
GitHub는 권고에 CVE를 할당합니다. AI 종말 이전에는 할당에 2-3일이 걸렸지만 지금은 3-4주가 걸려서 changelog에 CVE-PENDING을 넣고 포인트 릴리스를 보내야 합니다. 이는 이상적이지 않습니다.
해결책이 무엇인지 확실하지 않지만, 확실히 우리에게는 문제입니다.
- godelski
버그를 찾고 고치는 것이 더 쉬워졌지만, 그 어느 때보다 의지가 부족합니다. 제 상사들은 속도만 원하고, Claude가 5분 만에 해결하고 제가 검증했고 이미 공개 PR에 있는 버그를 해결할 필요가 없다는 30분짜리 강의를 합니다. 그러는 동안 우리는 점점 더 빠르게 버그를 쏟아내고 있습니다.
AI가 버그 수정에 아무리 뛰어나도, 고치려는 의지가 없다면 우리는 결코 고칠 수 없습니다. 좋은 소프트웨어를 만들려는 의지가 없다면 소프트웨어는 결코 좋아질 수 없습니다. 문제는 항상 의지에 관한 것이었습니다. 더 나은 제품이 너무 많습니다. 속도와 품질을 모두 향상시킬 수 있는 시대에 여전히 속도를 선택하고 그것을 속도라고 부르는 것은 미친 짓입니다.
- bri3d
이것이 LLM으로 인해 새로운 것은 아니라고 생각합니다 (몇 마디의 우연한 말을 바탕으로 익스플로잇을 찾는 것은 항상 익스플로잇 개발의 재미있는 부분이었습니다), 하지만 그것은 규모가 커지고 민주화되어 가치가 낮은 대상을 대규모로 착취하는 방향으로 나아갔습니다. 패치, 커밋 메시지, 우연히 듣거나 읽은 문장에서 익스플로잇 PoC를 추출하는 것은 취약점 연구만큼 오래된 관행입니다. LLM과의 차이점은 "충분히 숙련된" 행위자(인간이든 아니든)의 폭발적인 증가로 인해 엉성하거나 저숙련의 "인터넷 전체를 착취하는" 행위자들이 이전에는 불가능했던 방식으로 가능해졌다는 것입니다.
저자는 제 생각에 동의합니다; 대부분의 것은 훨씬 더 일찍 이루어졌어야 할 것들이며, 지금 강제 요소가 있다는 점에서 어느 정도 좋은 것 같습니다.
- stephbook
저는 출시와 배포가 더 큰 문제라고 생각합니다. 누가 10분 안에 소프트웨어 스택을 업데이트합니까? 대부분의 CI 실행은 비즈니스 로직이 여전히 작동하는지 확인하는 데 더 오래 걸립니다.
게다가 자동 업데이트를 원하지 않는 공급망 공격의 위험도 있습니다.
- rndhouse
저는 커밋을 모니터링하고 조용한 버그 수정을 감지하려는 도구를 만들었습니다. GPT-5.5급 모델을 사용하면 일상적인 커밋에 숨겨진 수정 사항을 상당히 안정적으로 식별할 수 있습니다. 감지를 피하기 위해 코드 변경을 난독화하는 것은 어렵습니다.
사용자가 안전하게 업데이트할 때까지 임시로 비공개 소스 바이너리를 릴리스한 프로젝트(c-lightning?)에 대해 들어본 적이 있습니다.
- ChrisMarshallNY
안타깝게도 여기서 얻을 수 있는 교훈은 저장소를 비공개로 유지하는 것 같습니다.
저는 그렇게 하는 것을 좋아하지 않지만, 많은 사람들이 그렇게 할 것이라고 생각합니다.
- jameshart
일반적으로 Claude가 소문을 바탕으로 그 버그가 있다고 가정하고 성공적인 익스플로잇을 찾을 확률이 얼마나 되는지 궁금합니다.
"이 패키지에 경로 탐색 익스플로잇이 있다고 들었습니다. 찾을 수 있나요?" - 아마도 그 소문을 지어낸 경우에도 찾을 확률이 상당히 높을 것입니다.
- janpeuker
새로운 버그에 대한 불안은 이해하지만, 솔직히 몇 년 안에 중간에서 높은 수준의 보안 버그를 수정하는 것이 너무 저렴해져서 일반 시민이 개인 정보 보호 위반을 찾아내는 저비용 해킹이 엄청나게 비싸지는 것이 더 두렵습니다.