요약
오픈AI의 자동 파이프라인이 리눅스 커널에서 루트 권한을 빼앗는 취약점 948개를 찾고 패치까지 만들었습니다.
오픈AI 사이버 팀이 11월 4일 공개한 연구입니다. 출시 예정인 사이버 보안 모델로 취약점 발견부터 익스플로잇(취약점을 실제로 공격하는 코드) 작성, 패치 생성까지 자동으로 돌렸습니다. 한 번 실행하는 데 든 API 비용은 약 121만 달러였습니다.
왜 중요한가
- 해킹 대회 상금으로 따진 결과물의 가치가 비용의 16~55배여서, 취약점 찾기가 이미 남는 장사가 됐습니다.
- 오픈AI는 당분간 패치가 밀린 시스템의 일반 계정을 사실상 루트 권한으로 봐야 한다고 경고했습니다.
- 새 모델이 7월의 GPT-5.6 Sol보다 5배 넘게 찾아, 모델이 바뀔 때마다 같은 코드를 다시 훑어야 합니다.
핵심 내용
- 보호 기능을 그대로 켠 일반 데스크톱 배포판에서 일반 사용자가 루트를 얻는 공격을 948건 완성했습니다.
- 후보 2,308건 중 1,724건이 실제로 재현됐고, 모델이 잘못 분석한 경우는 3.1%에 그쳤습니다.
- 표본 166개를 분석해 보니 외부 커널 전문가도 처음 보는 공격 기법이 10개 나왔습니다.
- 초기 실행의 성공 200건 중 20건은 배정받지 않은 다른 미공개 취약점으로 루트를 얻은 것이었습니다.
- 오픈AI는 심각한 취약점부터 패치를 붙여 보고했고, 10일 사이 61건이 이미 커널에 반영됐습니다.
HN 반응
- 커널에 구멍이 왜 이리 많은지를 두고, 성능을 위해 코드를 키운 탓이라며 OpenBSD를 예로 든 의견과 OpenBSD는 작고 덜 들여다봤을 뿐이라는 반론이 맞섰습니다.
- AI가 사람을 뛰어넘었다기보다 사람 수준의 기술을 엄청난 규모로 돌린 것이라는 평가에, 일부 이용자는 원문의 새 공격 기법 10개를 들어 반박했습니다.
커널에 권한 상승 익스플로잇이 천 개나 있는 지경에 대체 어떻게 이르렀을까요?
커널이 그냥 너무 복잡해서 머릿속으로 따져 볼 수 없는 수준이 된 걸까요? 아니면 보안 모델이나 언어 구현 자체에 근본적인 결함이 있는 걸까요?
그렇다면 다른 소프트웨어는 전부 커널보다 더 심하게 뚫려 있다고 봐야 하나요?
리눅스 개발에 돈을 대고 리눅스를 쓰는 대기업들이 보안보다 속도를 더 중요하게 여기기 때문입니다.
속도를 내려면 커널 안에 코드가 많아야 하고, 그래야 그 코드가 빠르게 돌아갑니다.
권한 상승 익스플로잇이 천 개씩 나오지 않는 커널도 있습니다. 이런 커널은 더 작아서 버그를 훨씬 쉽게 검사할 수 있습니다. 하지만 그런 커널은 눈에 띄게 느립니다.
많은 용도에서는 느려도 문제가 되지 않습니다. 하지만 리눅스 개발에 많은 돈을 대고 대형 데이터센터에서 리눅스를 돌리는 대기업에는 1%만 느려져도 추가로 필요한 서버 값이 말 그대로 수백만 달러입니다.
OpenBSD는 권한 상승 익스플로잇이 천 개씩 쏟아지지 않아도 유닉스 보안 모델을 갖출 수 있다는 걸 보여 줍니다. 그런데 OpenBSD는 10% 정도 느립니다. 그래서 기업들은 OpenBSD를 쓰지 않습니다. 연간 수백만 달러가 더 들고, 기업 소프트웨어 일부는 OpenBSD가 허용하지 않는 접근을 요구하기 때문입니다. 그런 접근은 바로 보안 익스플로잇으로 이어지기 때문에 막아 둔 것이고요(io_uring, eBPF 등등).
seL4 같은 것을 쓸 수도 있겠지만 그것도 느립니다.
그래서 이렇게 된 겁니다. 서버 비용과 해킹당했을 때의 비용을 저울질한 사업적 판단이고, 서버 비용이 이긴 것입니다.
정성 들여 짠 코드는 완벽하게 안전하다는 그림을 그리시는데, 그렇지 않습니다.
맞습니다, OpenBSD에서 버그가 쏟아져 나오지 않았죠. 하지만 제가 보기에 훨씬 큰 이유는 이 두 가지입니다. 1) 거의 아무도 쓰지 않는 OS의 버그를 찾으려고 토큰과 돈을 태우는 사람이 자릿수가 다를 만큼 적고, 2) 애초에 훨씬 작습니다. 블루투스 스택이 없으면 블루투스 버그도 있을 수 없으니까요.
저는 OpenBSD 쪽 코드에 LLM을 돌려 봤는데, cat이나 find 같은 가장 단순한 코드에서도 버그와 버퍼 오버플로가 나왔습니다.
OpenBSD는 패치 추적 시스템도 부실합니다. 아직 CVS를 쓰고 있어서요. 패치가 그냥 흐지부지 묻혀 버릴 확률이 아주 높습니다. 보안 패치든 아니든 마찬가지고요.
그러니 아닙니다. 안전한 C 코드를 쓸 수 있는 사람은 없습니다. 취미로 하는 개발자도, "그 사악한 기업들"도 마찬가지입니다.
Rust 컴파일러가 적용하는 검사들을 C 코드에 적용하지 못할 근본적인 이유는 없습니다. 그걸 훨씬 넘어서는 검사도 가능하고요.
여러 언어에는 극도로 신뢰할 만한 코드(심지어 정확성이 증명된 코드)를 만드는 도구가 있습니다.
하지만 그런 도구를 쓸 수 있는 만큼 쓰지 않는 경우가 많습니다. 아니면 프로젝트마다 개발 문화가 다르거나요. PHP로 웹 개발하는 사람과 항공전자 소프트웨어를 만드는 사람은 (평균적으로) 쓸 수 있는 자원도, 우선순위도, 일하는 태도도 다르기 마련입니다.
AI든 고급 도구든 보안 연구자든, 기존 코드에서 버그를 찾아낼 수 있다면 (적어도 이론상) 그 버그는 저장소에 올라가기 전에도 찾을 수 있었다는 얘기입니다.
그런데 아니죠... 일단 "릴리스"부터 누르고, 문제는 신고가 들어오면 그때 고칩니다. 개발 속도가 생명이니까요, 안 그래요?
제 생각엔 "X로는 안전한 코드를 못 쓴다"기보다 선택의 문제입니다.
못 믿겠다면 아무 오픈소스 프로젝트나 골라서 변경 내역을 쭉 훑어보세요. 버전 X에서 넣은 기능이 X+1에서 깨진 게 있어서 되돌려지고, 몇 년째 안 돌아가던 기능이라 삭제되고, X를 하는 코드를 추가했다더니 아니 X는 안 하고 다음 버전에서 X를 하기 위한 뼈대만 들어 있고, 시스템 A에서는 잘 돌아가고 테스트도 통과했는데 엔디안이 다른 플랫폼 B에서는 바이트 스왑이 필요한 것으로 드러나고.
이런 일이 끝도 없이 나옵니다. 첫날부터 망가져 있던 코드가 정말 많습니다. 게다가 그걸 알면서도 릴리스한 경우가 드물지 않고요.
저도 Rust를 몸에 익힌 뒤에 제 C++ 코드를 어떻게 개선할지 생각해 봤습니다. 안타깝게도 건질 게 거의 없었습니다. Rust의 안전 장치를 하나 구현할 때마다, 그걸 (실수로) 쉽게 깨뜨리는 방법이 같이 떠올랐거든요.
그래서 언어 안에서 해결되면 좋겠지만 저는 잘 모르겠습니다.
"충분히 똑똑한 컴파일러"만 나오면 정말 좋겠죠. 하지만 현실은 대개 그렇게 흘러가지 않습니다. (참고: https://wiki.c2.com/?SufficientlySmartCompiler )
형식 검증된 코드는 많이 살펴보지 않았지만, 그런 코드라면 물론 가능합니다. 다만 형식 검증된 코드에서도 버그가 나온 사례는 많습니다. 일부는 엉뚱한 것을 검증했기 때문이고요. 그 밖에도 어떤 프로젝트에든 "그냥" 형식 검증을 얹을 수는 없는 이유가 있는 것으로 알고 있습니다.
어쩌면 AI가 완벽한 어셈블리를 바로 짤 수도 있겠죠. 그러면 우리 모두 언어 논쟁을 그만둘 수 있겠네요.
어쨌든 제가 말한 "안전한 C(또는 UB 없는 C)를 쓸 수 있는 사람은 없다"에 반박하려는 논거가 "AI가 모든 줄을 검증하면 가능하다"라면, 그야 그렇겠죠. 하지만 1) 그럼 그 코드를 실제로 쓴 건 누구입니까? 그리고 2) 사람이 C 코드를 쓰는 데 관여했다면 십중팔구 나아지기는커녕 나빠졌을 겁니다.
AI가 C를 짜더라도 LLM의 컨텍스트에서 한 가지만 빠져도 버퍼가 넘칠 수 있습니다. 반면 (전부는 아니어도) 많은 종류의 버그에서는 unsafe 없는 Rust와 형식 검증된 코드의 차이가 중요하지 않습니다. 즉
unsafe를 쓰지 않고 컴파일이 된다면, 메모리 안전성에 대해서는 굳이 형식 검증까지 할 필요가 없다는 말입니다.요즘은 릴리스를 내기 전에 변경분을 AI에게 최소한 검토시키지 않는 것은 직무 유기라고 봅니다. 운영 서버에서 라이브로 Perl cgi-bin을 에디터로 직접 고치는 것과 같습니다. 그건 "프로덕션"이 아니에요.
제가 말하는 프로덕션이 아니라는 게 바로 이런 경우입니다. 자기 블로그를 라이브로 막 고치거나, "내 용도엔 잘 돌아가고, GPL이고, 있는 그대로 제공하니까 귀찮게 하지 마" 하는 걸(아마 대부분의 오픈소스가 이럴 겁니다) 두고 뭐라고 하지는 않겠습니다. 잘 돌아가든 말든 상관없다면야 괜찮습니다.
하지만 잘 돌아가는지, 안전한지에 신경을 쓰면서 AI 검토 없이 릴리스를 내보낸다면 해고감입니다.
네, 지금의 상태에서 거기까지 가야 합니다. 코드베이스 전체의 밀린 부분을 AI로 다 고칠 때까지 릴리스를 동결하자는 얘기는 아닙니다. 다만 오늘날에는 릴리스 변경분을 AI에게 검토시켜야 합니다. 이상적으로는 커밋 전에요.
CVS라니요! 말도 안 되네요. 라이선스 때문에 SVN이 싫었나 보죠? 그게 아니면 이렇게 조잡하고 낡은 SCM 시스템을 굳이 쓸 이유를 모르겠습니다.
개발 모델이 다릅니다. 상근 개발자, 즉 "커미터" 말고는 협업하기 어려운 모델이죠.
SVN은 제대로 만든 CVS입니다. 하지만 모델 자체가 열린 개발에 비효율적이라서 그냥 고쳐 쓸 수가 없습니다.
"got"( https://gameoftrees.org/ )으로 자체 개발(NIH)을 하는 것 같은데, FAQ를 보면 너무 노골적으로 외부인을 반기지 않는 분위기라서, 저를 원하지 않는 곳에 시간을 들여 들여다보고 싶지는 않습니다.
말씀 참 거침없으시네요...
깎아내리려는 게 아닙니다. 0.1%도 안 되는 점유율이면 "거의 아무도 안 쓴다"는 말이 정확합니다.
저는 OpenBSD를 이론상으로는 좋아하지만, 써 보려고 할 때마다 실용적인 문제가 발목을 잡았습니다.
오래된 글이지만 2019년에 쓴 제 생각은 이렇습니다: https://blog.habets.se/2019/10/OpenBSD-in-2019.html
저는 OpenBSD 편이지만, 궁금한 건 OpenBSD도 이번 리눅스 익스플로잇을 찾은 것과 같은 방법으로 시험해 봤느냐는 겁니다.
저는 AI에도 꽤 적대적인 편이지만, 이 기계들이 익스플로잇을 찾는 데 아주 뛰어난 건 인정합니다.
OpenBSD에서 LLM이든 에이전트든(뭐라고 부르는 게 맞는지 모르겠지만) 이것저것으로 침투 테스트를 하거나 틈을 찾으려는 프로젝트가 어디선가 분명 있었을 겁니다.
물론 OpenBSD는 일부러 공격 표면을 훨씬 줄여 놨으니 전반적으로 더 안전하길 바랍니다. 하지만 숫자로 보고 싶습니다.
얼마 전에 뭔가 발견된 적은 있는 걸로 아는데, 한두 건이었지 수천 건은 아니었습니다.
에이전트들이 달려들고도 진짜로 버텨 낸 OS는 seL4뿐인 것 같은데, 제가 틀렸을 수도 있습니다.
그러면 지금 다시 확인해 봐야 합니다. 6개월 전의 최신 모델은 지금의 최신 모델이 한참 뛰어넘었으니까요.
BSD를 쓰는 컴퓨터는 아주 적습니다. 중요한 컴퓨터가 있긴 하겠지만, 표적 목록 상위에 오르는 경우는 별로 없습니다.
BSD를 전부 한데 묶는 건 잘못입니다. 하나에서 찾은 익스플로잇은 다른 BSD에는 아마 통하지 않을 겁니다.
해킹당했을 때 치르는 비용이라는 게 실재하는 것 같지도 않으니, 보안에 투자할 유인이 이보다 낮을 수가 없죠. 소니나 PSN이 지금까지 몇 번이나 해킹당했습니까? 회사 규모가 일정 수준을 넘으면 그냥 상관이 없습니다. 은행도 해킹당하고요. 온갖 업종의 거대 기업들이 다 그렇습니다. 제 정보도 아마 다크웹에 다 풀려 있을 겁니다. 당신 것도 마찬가지고요. 그래서 결국 뭐가 어떻게 됐습니까? 실질적으로 뭐가요. 저는 겪은 게 없습니다. 소니도 겪은 게 없고요. 누가 겪었나요? 아무나요? 해킹 기사는 수도 없이 읽는데, 정작 현실에서 실제로 피해를 본 사람의 이야기는 단 하나도 못 봤어요. 어떻게 그럴 수가 있는지. 정말 모르겠습니다. 수십 년 전에 진작 바퀴가 빠졌어야 할 것 같은데 다들 아무 일 없다는 듯 굴러가고 있습니다. 내일 또 유출이 터져도 아무 일 없다는 듯 굴러가겠죠. 익스플로잇은 더 나오고, 제로데이도 더 나오고. 그래도 해는 뜰 겁니다.
많은 분들이 이걸 자기가 늘 말하던 주제로 끌고 가는 것 같은데, "시스템이 복잡하다"는 점과 "프런티어 연구소들이 해킹에서 인간을 초월하는 모델을 만들었다"는 점만으로도 충분한 설명 같습니다.
저는 LR2021이라는 LoRa 칩을 가지고 작업 중입니다. 개발 보드를 컴퓨터에 꽂고 Claude에게 리버스 엔지니어링을 시켰습니다. Claude는 믿기지 않는 속도와 효율로 이 칩을 해부했습니다. 몇 시간 만에, 제조사만 쓰라고 만든 완전히 불투명한 패치 RAM 영역에 넣을 맞춤 패치를 Claude가 쓰고 있었습니다. 이 내용은 여기에 썼습니다: https://beala.substack.com/p/your-node-doesnt-need-a-microcontroller
지금까지 본 결과물은 인간을 초월한 해킹 실력이라기보다 인간의 실력을 초인적인 규모로 돌린 것에 가깝습니다.
이 버그들은 하나하나가 수십 년 전부터 우리가 찾아서 고쳐 오던 것과 같은 유형입니다. 다만 그걸 예전과는 비교도 안 되게 큰 규모로 확장할 방법을 찾은 거죠.
우리가 같은 보고서를 읽은 게 맞나 싶네요.
"에이전트가 개발한 익스플로잇 166개를 표본으로 뽑아 사용된 익스플로잇 기법을 분석했습니다. 저희가 아는 한, 에이전트들은 표본 익스플로잇에서 새로운 익스플로잇 기법 10개를 사용했습니다. 이 기법들을 외부 커널 익스플로잇 전문가들에게 공유했는데, 그들에게도 새로운 기법이었습니다. 10개의 기법 가운데 둘은 모델이 대상 커널 캐시 안에 객체를 스프레이하는 데 쓴 새로운 영속 탄성 객체이고, 둘은 익스플로잇의 신뢰성을 높이는 새로운 페이지 그루밍 기법이며, 다섯은 권한 상승을 직접 얻거나 임의 쓰기를 통해 얻는 새로운 데이터 전용 기법입니다. 나머지 하나는 임의 타입 혼동에 관한 기법입니다."
맞습니다. 에이전트는 사람보다 n제곱 배 넘는 양을 읽고 쓰고 컨텍스트를 유지할 수 있는 데다 에이전트 수까지 곱해지니, 갑자기 가장 잘 교육받은 "두뇌" 5만 개가 1만 배 빠른 속도로 지루하거나 난해하거나 4시간 넘게 걸리는 작업에 달려드는 겁니다.
스케일이에요, 베이비!
Claude가 비공개 문서나 코드로 학습했을 가능성, 심지어 불법으로 입수한 자료일 가능성도 배제하지 마세요. 그렇다고 Claude가 덜 유용해지는 건 아닙니다. 다만 꼭 당신이 생각하는 이유 때문은 아닐 수 있다는 겁니다.
저도 E-Ink 디스플레이를 다룰 때 그런 일이 있었습니다. Claude가 저는 전혀 모르고 문서도 없는 오퍼레이션 코드를 쓰더군요.
문제없이 잘 동작했지만 솔직히 말해 봅시다. Claude가 임의의 숫자를 데이터 조각과 함께 넣어 보고 전자종이가 어떻게 반응하는지 관찰한 건 아니잖아요.
제 첫 번째 추측은 인터넷 어딘가의 이름 모를 저장소에 누군가 이 숫자들을 알아내서 올려 뒀고 Claude가 그걸 "기억"하고 있다는 겁니다.
그런 건 보통 쉽게 못 찾는 데이터시트에서 나오거나, 같은 일을 하는 비슷한 다른 코드에서 나옵니다.
데이터시트는 찾기가 거의 불가능하고, 업체들은 보통 더 저렴한 원제조사를 숨기고 재판매하기 때문에 공유할 유인이 없습니다.
그럴 수도 있지만 두 가지가 떠오릅니다.
제 경험이 특별한 게 아닙니다. 소셜 미디어에는 프런티어 모델이 해낸 비슷한 초인적 리버스 엔지니어링 사례가 넘쳐 납니다. 예를 들어 누군가는 AI로 Rigol 장비(오실로스코프 등)용 대체 OS를 만들었습니다 [1]. 이게 전부 학습 데이터에 들어 있었다는 건가요?
Claude가 일하는 걸 지켜보니 정말로 리버스 엔지니어링을 하는 과정을 밟는 것 같았습니다. 먼저 ROM을 덤프하고, 디스어셈블하고, 문서화되지 않은 오퍼레이션 코드를 식별했습니다. 여러 메모리 영역을 탐색하려고 테스트 프로그램도 많이 만들었고요. 제게는 아주 꼼꼼하게 보였습니다.
이 중 어느 것도 일부가 이미 학습 데이터에 있었다는 생각과 양립하지 못하는 건 아닙니다. 다만 AI가 보이는 만큼 실제로 뛰어난 건 아닌 이유를 어떻게든 항상 찾아내려는 충동에는 반박하고 싶습니다. 이제는 인간 프로그래머가 이미 추월당하고 있다는 사실을 받아들여야 한다고 봅니다. 네, 저도 그게 무섭습니다.
[1] https://aioscilloscope.com/
이런 터무니없는 "만약에"가 정말 중요한가요? 요점이 뭐죠? 이런 작업이 가능하도록 학습됐다는 거요? 그건 물이 젖어 있다고 경고문을 붙이는 거나 다름없습니다.
함의는 이겁니다. 첫 원리에서 리버스 엔지니어링을 해내는 어떤 초지능이 아니라 정답 자체를 먹여 준 것일 수 있다는 겁니다. 설계 문서를 베끼고 있는 거라면 리버스 엔지니어링이라고 하기 어렵습니다.
그렇다고 오직 그것뿐이라는 건 아닙니다. 하지만 제가 지금까지 본 놀라운 성과 대부분은 모델이 비공개 데이터로 학습됐다고 하면 쉽게 설명됩니다. 대기업들이 다크웹을 포함해 긁을 수 있는 건 직간접으로 다 긁어 간다는 건 확실한 사실입니다. 간접적이라는 건, 최소한 일부 경우에는 그 데이터에 대한 권리가 없는 제3자에게서 데이터를 사 오는 것을 말합니다. 불법 복제된 학술지 데이터베이스나 멀티미디어 같은 것들이요. 내부 기밀 문서까지 손에 넣었다고 가정하는 게 그렇게 억지일까요? 이런 자료가 전에도 유출된 적이 있다는 건 알려져 있습니다. 다만 구글로 쉽게 검색되지 않았을 뿐입니다.
아니 ㅋㅋ 완전 헛소리입니다. 기사 내용과도 안 맞고요.
이 하위 스레드의 맥락은 마이크로컨트롤러와, 거기서 비공개 기능을 찾아낸 이야기입니다.
함의는 기업과 연구자들이 OpenAI를 쓰면서 기밀 데이터를 유출하고 있고, 자기 작업물을 지키려면 이에 대해 뭔가 조치를 취해야 할 수도 있다는 겁니다.
그건 저도 개인적으로 걱정하는 부분입니다. 대기업들이 AI 회사와 계약서를 쓸 때 회사 데이터의 학습과 보관을 특별히 금지하도록 명시한다는 건 제가 직접 아는 사실입니다. 다만 기본으로 제공되는 클릭 동의 계약서는 읽어 보지 못했고, AI 회사들이 실제로 그렇게 한다는 독립적인 확인도 본 적이 없습니다. 모델에 가능한 한 많은 데이터를 먹이는 게 이 판의 법칙인 것 같으니, 그렇게 하지 않는다면 조금 놀랄 것 같긴 합니다.