Hacker News 의견들

• GPT‑5.2에게 가장 어려운 과제로 디스크의 특정 경로에 문자열을 쓰는 방법을 찾게 했음
  ASLR, 비실행 메모리, full RELRO, 세밀한 CFI, 하드웨어 shadow‑stack, seccomp 샌드박스 등 모든 보호가 켜진 QuickJS 환경이었음
  GPT‑5.2는 glibc의 exit handler 체인을 이용해 7단계 함수 호출로 문제를 해결했음. 정말 놀라운 결과였음

  • 이런 완화책들을 아예 제거해야 하는 게 아닐까 생각함
    실제 익스플로잇은 대부분 “취약점 찾기(어려움)” 후 “쓸모없는 완화책 여러 겹 뚫기(귀찮지만 가능)” 순서로 진행됨
    확률적 완화는 확률적 공격엔 통하지만, 공격자는 의도적으로 약점을 찾아냄
  • 결국 기계어 스택 하단엔 구멍이 너무 많음
    미래엔 왜 더 일찍 WASM으로 전환하지 않았는지 후회할 것 같음
    그 전까지는 하드웨어 완화책을 덕지덕지 붙이며 낡은 스택 오버라이트 문제를 붙잡고 있을 것임
  • “glibc의 exit handler”라니… 소름임
  • 요즘 킬체인은 대부분 여러 버그를 연쇄적으로 이용함
    내 일이라 잘 아는데, 점점 무력감이 커지고 있음
  • 이런 사례는 C로 빌드된 QuickJS가 얼마나 LLM에게 취약한지 보여줌
    Use‑After‑Free로 libc 포인터를 유출하는 식임
    Rust라면 훨씬 어렵겠지만, libc 호출이 많으면 완전한 방어는 어려움

• GPT‑5.2의 익스플로잇은 완화책을 새로 깨뜨린 게 아니라, 이미 알려진 구현상의 틈을 이용한 것임
  인간 해커도 마찬가지로 완화책 자체를 새로 깨지 않음
  다만 CTF 분야에서는 LLM이 이제 원샷으로 pwn 문제를 푸는 경우가 늘고 있음
  이런 발전 덕분에 불완전한 완화 구현들이 무너지고, 형식적 익스플로잇 모델링 연구가 촉진될 것 같음

  • “형식적 익스플로잇 모델링”이 미성숙한 분야라는데, 참고할 만한 자료가 궁금함

• 보안 연구자로서 보면, LLM이 만든 read/write primitive API는 기존 API를 단순히 재조합한 수준임
  새 기술이라기보단 CTF용 장난감 바이너리와 비슷함
  다만 최신 OpenAI 모델이 실제 익스플로잇 코드를 생성하지 않으려는 경향이 있는데, 프롬프트 우회가 쓰인 건지 궁금함

• 저자는 흥미로운 포인트를 짚었지만, 나는 크게 걱정하지 않음
  이런 도구는 방어자도 대칭적으로 활용 가능함
  CI 단계에서 “LLM Red Team”을 돌리는 식으로 자동 보안 테스트를 추가할 수 있음

  • 수학적으로 보면 대칭이 아님
    공격자는 한 번만 성공하면 되고, 방어자는 항상 성공해야 함
    현재 모델은 pass@x 성능이 maj@x보다 20~30% 높음
    그래도 Red vs Blue 루프를 돌리면 보안 수준은 개선될 것임
  • 복잡한 시스템에서는 이런 대칭이 깨짐
    공격자는 한 번의 실패만 찾아내면 되고, 방어자는 모든 걸 막아야 함
  • 이미 방어적으로도 사용 중임
    예: Google Project Zero의 Big Sleep 프로젝트
    관련 취약점 목록은 이곳에서 볼 수 있음
  • 대칭이 될 수 없음
    공격자는 하나의 버그만 찾아도 무기화 가능하지만, 방어자는 모든 버그를 찾아야 함
    “any vs all”의 비대칭 구조임
  • 유지되지 않는 소프트웨어가 너무 많음
    결국 LLM 기업만이 진정한 승자가 되어 양쪽에 토큰을 팔게 됨

• Codex 5.2가 가장 복잡한 익스플로잇을 찾아낸 점이 흥미로움
  나도 Opus 4.5를 주로 쓰지만, Codex 5.2의 Extra High thinking 모드는 확실히 강력함
  LLM 발전이 둔화됐다는 말은 믿지 않음. 오히려 과제가 너무 어려워져서 체감이 줄었을 뿐임

  • 실제로는 익스플로잇을 “찾은” 게 아니라, 이미 주어진 취약점을 활용하는 코드를 작성한 것임
    로그는 이 저장소에서 확인 가능함
  • Anthropic 모델은 도구 사용자형, OpenAI Codex High는 리뷰어/수정자형, Gemini는 창의적 예술가형임
    각자 스타일이 다름
  • “충분히 어려운 과제”는 대부분 기업 내부 IP로 묶여 있음
    상업적 가치가 사라질 때까지 공개되지 않음

• QuickJS는 원래 패치되지 않은 취약점이 많은 장난감 프로젝트임
  curl 같은 실전 대상에서의 익스플로잇이 더 흥미로울 것임

• LLM이 훌륭한 익스플로잇을 쓴다는 주장과, 쓸모없는 버그 리포트를 낸다는 주장이 공존함
  둘 다 사실일 수 있을까?

  • 둘 다 충분히 가능함
    LLM의 품질은 사용자 프롬프트와 해석 능력에 따라 달라짐
    전문가가 선별적으로 활용하면 훌륭한 결과를 얻을 수 있음
  • 익스플로잇은 “작동하느냐”로 명확히 평가되지만, CVE 리포트는 검증이 훨씬 힘듦
    자동 생성된 리포트는 유지보수자에게 큰 부담임
  • 실제로는 사용 방식에 따라 품질 차이가 큼
    단순히 “이 프로그램의 취약점을 찾아줘”라고 하면 헛소리가 많지만,
    테스트 루프와 환경을 제공하면 반복적으로 개선해 진짜 동작하는 결과를 냄
  • 익스플로잇은 명확한 성공 기준이 있고, LLM의 집요한 반복성과 잘 맞음
    반면 버그 리포트는 모호하고 평가가 어려움
  • 예산 구조도 다름
    예를 들어 $100 중 $50짜리 진짜 이슈 하나와 $0.01짜리 5000개의 가짜 리포트가 섞여 있으면,
    진짜 다이아몬드를 찾기 어렵게 됨

• 샌드박스 설명이 모호해서 처음엔 의심스러웠음
  저자 저장소를 보니 “/tmp/pwned에 ‘PWNED’ 문자열을 쓰는 것”이 목표였음
  즉, 샌드박스 탈출이 아니라 단순 파일쓰기 제한이었음

  • 전체 리포지토리와 글이 다소 오해를 부를 만한 구성임
    OOB R/W primitive API를 만들게 한 것도, 이미 수천 개의 GitHub 예시를 재활용한 수준임

• “앞으로 국가나 조직의 해킹 역량은 해커 수가 아니라 토큰 처리량으로 결정될 것”이라는 말이 인상적이었음

  • 실제로는 그런 조직들이 LLM의 허술한 코드 패턴을 분석해, 사람이 직접 범용 익스플로잇을 작성하고 있을 가능성이 큼

• 소프트웨어 제작의 진입장벽과 해킹의 진입장벽이 동시에 낮아지는 건 폭발적인 조합임
  이제는 보안 가드레일과 검증 가능성을 갖춘 새로운 플랫폼이 필요함
  비전문가가 만든 코드에 의존하기엔 위험함

  • 원래 세 번째 문단에서 “단 하나의 익스플로잇 vs 전체 시스템 방어”의 불균형을 언급했는데, 왜 삭제했는지 궁금함