요약
PHP2Shell 취약점은 AI가 40년 묵은 코드의 허점을 캐내는 시대가 왔다는 경고입니다.
IEEE 스펙트럼의 디나 겐키나 기자가 10월 말 공개된 PHP 취약점 PHP2Shell을 계기로 쓴 기사입니다. 미 항공우주국(NASA), 위키백과, 백악관 누리집과 수많은 WordPress·Drupal 사이트가 위험에 놓였지만, 다행히 공격에 쓰이기 전에 패치됐습니다.
왜 중요한가
- 사소한 충돌로 여겨 미뤄 둔 오래된 버그도 AI의 도움을 받으면 심각한 공격 수단이 될 수 있습니다.
- AI는 최고 전문가의 작업량을 늘리고, 덜 숙련된 사람도 더 깊은 공격에 손댈 수 있게 해 줍니다.
- 버그 찾기는 쉬워졌지만 고치기는 여전히 어려워서, 수입원이 없는 오픈소스 프로젝트가 가장 큰 부담을 집니다.
핵심 내용
- 문제의 버그는 2024년에 이미 PHP 재단에 보고됐지만, 프로그램이 멈추기만 하는 메모리 부족 오류라 뒤로 밀렸습니다.
- 오픈AI가 후원한 캘리프의 보안 감사에서 한 연구자가 AI 도구로 2주 만에 이를 임의 코드 실행(공격자가 원하는 코드를 돌리는 것)으로 키웠습니다.
- 반면 모든 공격 경로를 막으면서 기존 기능도 지켜야 하는 패치는 4명이 두 달에 걸쳐 만들었습니다.
- 컬럼비아대 수만 자나 교수는 AI 연구소의 토큰 지원을 늘리고, AI가 패치와 함께 정확성 증명까지 내놓는 형식 검증을 쓰자고 제안했습니다.
- 존스홉킨스대 매슈 그린 교수는 큰 사고가 나기 전에는 대응이 없을 것이라며, 보안 업데이트를 바로 설치하라고 당부했습니다.
HN 반응
- 일부 이용자는 국가 기관이나 스파이웨어 업체가 숨겨 둔 제로데이(아직 알려지지 않은 취약점)도 이 과정에서 드러나 결국 더 튼튼한 소프트웨어가 남을 것이라고 기대했습니다.
- AI로 코드를 증명하면 된다는 주장에는 증명이 버그 없음을 보장하지 않는다는 반론이 나왔고, AI가 검증되지 않은 새 코드를 대량으로 쏟아낸다는 지적도 이어졌습니다.
국가나 Pegasus 같은 기업형 스파이 업체들이 꽁꽁 숨겨 둔 백도어나 제로데이 중 일부가 이 난리통에 우연히 발견되고 있으면 좋겠네요.
지금은 패치해야 할 제로데이와 CVE가 쏟아져서 짜증스럽지만, 길게 보면 우리가 더 튼튼한 소프트웨어를 손에 쥐게 될지도 모르죠.
AI의 능력이 인간이 만든 소프트웨어를 스트레스 테스트한다는 흐름을 논리적으로 끝까지 밀고 가면, 결론은 모든 버그를 찾아낼 수 있게 된다는 것입니다. 그러니 목표는 실제로 버그가 없는 소프트웨어일 수밖에 없습니다.
그렇게 하는 유일한 방법은 코드를 증명 가능하게 만드는 것입니다. 그것 역시 현실적으로는 AI를 써야만 가능합니다.
그 과정에서 사람들은 "소프트웨어 엔지니어링"이라는 허울을 현실로 만들어야 할 것이고, 엔지니어링이라는 부분을 분명히 드러내야 합니다.
그건 인간이 자기가 무엇을 하고 있는지 실제로 이해할 때만 가능합니다.
코드가 올바르다는 것을 증명했다고 해서 그 코드가 절대 틀리지 않는다는 뜻은 아닙니다. 특히 HN의 많은 사용자가 지적하듯, 여러 인터페이스나 복잡한 요소가 결합되면 오동작을 일으키기 쉬운 복잡성이 얽혀 있습니다. 예를 들어 '사용자'가 드라이버를 'db.backend.sqlite3' 대신 'db.backend.sqlite'로 설정하면, 갑자기 예상치 못한 설정이 되어 버리는 식입니다.
혹시 이걸 말씀하시려던 건가요? “프로그램 테스트는 버그가 있다는 것을 보여줄 수는 있어도, 버그가 없다는 것을 보여줄 수는 결코 없습니다!” ― 에츠허르 W. 데이크스트라
아니면 저도 데이크스트라가 한 말이라고 생각했던 두 번째 인용일 수도 있고요. “소프트웨어 설계를 구성하는 방법은 두 가지입니다. 하나는 너무 단순해서 결함이 없다는 것이 자명하도록 만드는 것이고, 다른 하나는 너무 복잡해서 눈에 띄는 결함이 없도록 만드는 것입니다.” C.A.R. 호어, 1980년 ACM 튜링상 수상 강연
아니요, 크누스 맞습니다. 정확한 문구는 "위 코드에는 버그가 있을 수 있으니 조심하세요. 저는 이 코드가 올바르다는 것을 증명했을 뿐, 실행해 보지는 않았습니다."입니다. 1
네, 엉뚱한 것을 증명하는 것도 얼마든지 가능합니다.
그래서 LLM만 관련 지식을 알고 있는 걸로는 충분하지 않습니다.
동물원을 동물들에게 운영시킬 수는 없습니다.
엄밀히 따지면 동물원은 전부 동물이 운영하는 거 아닌가요? :D
딱 어울리네요. 우리는 설계의 복잡성을 가둬 보려고 애쓰는데, 정작 우리 자신이 판아키(panarchy)적인 하이퍼시스템이니까요.
상관없는 얘기지만 "Panarchical Hypersystems"는 회사 이름으로 아주 좋겠네요.
아니면 록밴드 이름으로요. (데이브 배리에게 경의를 표하며.)
이시와타리 다이스케 작품에 나올 법한 비밀결사, 아니 비밀 초병기 독점 기업처럼 들린다는 점과도 딱 맞아떨어지고요.
그 얘기가 나왔으니 말인데, "Esoteric Superweapon Monopoly Corp"도 마찬가지로 밴드 이름으로 아주 좋겠네요.
지능이 낮은 동물들... 아, 잠깐만요
예전에 국립공원에 놓는 쓰레기통을 설계하는 사람의 인터뷰를 본 적이 있습니다. 이 일에서 가장 어려운 점이 무엇이냐는 질문에 그는 이렇게 답했습니다. "가장 멍청한 인간과 가장 똑똑한 곰이 상당 부분 겹친다는 점을 감안해야 하는 겁니다."
연구자들이 우리 코드 서명 시스템이 건전하다고 "증명"한 뒤로도 몇 달 동안 저는 그 시스템에서 보안 구멍을 계속 찾아냈습니다. 지금까지도 그들이 무엇을 증명한 건지 모르겠습니다. 아키텍처가 동작한다는 것을요? 그건 이미 백 명에게 증명해 보인 사실이었습니다.
맞아요, LLM이 없던 시절에는 모든 코드가 완벽하고 버그도 없었으니까요.
코드가 올바르다는 것을 증명했다고 해서 그 코드가 절대 틀리지 않는다는 뜻은 아닙니다.
신은 자기도 찾지 못하는 제로데이를 만들 수 있을까요?
세상의 엉터리 암호 코드 대부분은 만든 본인도 깰 수 없는 것들입니다.
제 생각에는 지금 LLM은 이걸 할 수 없고 사람은 할 수 있지 않나요?
또 방어적 프로그래밍의 상당 부분이 애플리케이션과 런타임 계층에 떠넘겨진 데에는, OS의 보안 모델이 낡았고 권한 체계가 지나치게 뭉툭하다는 이유도 있습니다. 화이트리스트에 오르지 않은 파일은 읽을 수 없도록 권한 시스템이 보장해 준다면, 모든 경로를 일일이 검사하면서 그걸 완벽하게 해내지 않아도 되니 올바른 프로그램을 짜기가 훨씬 쉬워집니다.
저는 직관이 정반대인데요? 최근 나오는 수학 성과는 정리 증명기(theorem prover)로 이루어지고 있습니다. LLM은 이 분야에서 매우 뛰어나지고 있고, 인간이 증명해 온 범위를 넘어서고 있습니다. 검증된 코드는 전통적으로 사람이 하면 비용이 아주 많이 들어서 틈새 분야에서만 쓸 수 있었습니다.
하지만 그 반대가 사실이었다면 증명 자체가 불가능했을 겁니다. AI는 인류가 내놓은 모든 해법으로 학습하잖아요. LLM은 거인의 어깨 위에 서 있는 것이지, 그 반대가 아닙니다.
현재로서는 인간에게서 나온 학습 데이터가 전체 학습에서 차지하는 비중은 극히 미미합니다. 프런티어 모델 학습의 압도적 다수는 합성된 RLVR 데이터입니다. 9가 몇 개나 붙는지는 영업 비밀이고요. 이 분야를 잘하게 된 것도 그 덕분입니다.
RLVR이 학습의 3분의 1 정도(많아야 3분의 2?)밖에 안 되는 줄 알았는데요?
그 비중은 달마다 커지고 있습니다. 지난여름부터는 새로 들어오는 GPU 하드웨어 거의 전부가 추론과 포스트 트레이닝 모델 튜닝, 대체로 RLVR에 쓰이고 있습니다.
우리도 그래요. 우리 역시 똑같은 선행 해법들로 훈련받았으니까요.
LLM은 원칙적으로 인간이 할 수 있는 모든 일을 할 수 있습니다. 어쩌면 그 이상도요. "지금"이 대체 언제까지입니까? 사람이 느린 겁니다.
"증명 가능"하다는 것은 본질적으로, 명시적인 상태에 명시적인 연산자가 작용하고, 그것이 "참"과 명시적으로 정의된 불변식을 보존하는 방식으로 빠짐없이 정의되어 있다는 뜻입니다.
결정론적으로 따져 볼 수 있는 유한한 대상이라는 것이죠.
당연히 여기서 따져 보는 "주체"는 LLM이고, 코드가 돌아가는 머신 또한 똑같이 엄밀한 방식으로 정의되어 있어야 하며, 이런 식으로 이어집니다.
그것만으로도 충분하지 않습니다. 추상화, 즉 여러분의 의도를 보존하고 문제 공간을 정확하게 기술하는 범주의 계층 구조가 필요합니다.
그러면 "프로그래밍"은 그 계층 위에서 역문제(inverse problem)를 푸는 일이 됩니다. 모델 계층을 따라 내려가면서 빈칸을 합리적으로 채워 나가, 마침내 (증명된) 하드웨어가 이해하는 원자적 명령어까지 도달하는 것이죠.
현재 대부분 빠져 있는 것이 바로 그런 제대로 된 추상화 계층입니다. 정확히는 어렴풋이 흉내만 내고 있는 수준이죠.
다시 말해, 그렇습니다. 지금 상태는 엉망입니다. 그걸 바로잡는 일은 결코 쉽지 않습니다.
하지만 선택의 여지가 없습니다. 그 엉망인 상태는 충분히 큰 LLM에게는 훤히 들여다보입니다. 모호함에 기대는 보안(security by obscurity)은 한계가 있습니다.
충분히 큰 LLM에게 훤히 들여다보이는 건 자원이 충분히 주어졌을 때의 얘기입니다. 이건 예전부터 늘 그랬던 사실이고요. 달라진 점은 필요한 자원의 수준이 낮아졌다는 것이고, 그래서 예전에는 경제성이 없어 찾지 않던 것들을 잔뜩 찾아내고 있는 겁니다.
하지만 비용이 0이 된 것은 아닙니다. 게다가 같은 LLM들이 이제 엄청난 양의 새 코드를 쏟아내고 있는데, 그 코드를 그만큼 엄밀하게 검증한 사람은 아무도 없고, 기존 코드나 다른 새 코드와 어떻게 상호작용하는지 생각해 본 사람조차 없습니다.
이 부분에는 동의합니다. 제 관점에서는 이론적인 해법은 있지만 사용성이 없고, (형식적으로 증명·검증되었다는 의미에서) 증명되지 않은 메커니즘에 의존하고 있다는 겁니다. WASM + 권한 전달(capability passing)이면 충분하지만, WASM 계층도 결국 증명되지 않은 OS나 런타임 위에 올라가 있어서 그 위에 제품을 만들려면 엄청나게 고생할 겁니다.
LLM은 백플립 못 하잖아요. 저는 하는데요.
유니트리의 H2-X는 할 수 있습니다.
https://youtu.be/Y3zb4o47yqA
유니트리 h2-x가 LLM이에요?