요약
OpenBSD 커널의 공유 메모리 코드에 37년 동안 숨어 있던 버그로 루트 권한을 얻을 수 있었습니다.
보안 연구 업체 칼리프의 앤드루 그리피스가 10월 16일 공개한 분석입니다. 칼리프는 올해 초 이 버그를 포함한 여러 취약점을 수정안과 함께 OpenBSD에 제보했고, 수정이 배포된 뒤 글을 냈습니다.
왜 중요한가
- 보안을 앞세우는 운영체제에서도 오래된 설계 가정 하나가 수십 년 동안 공격 통로로 남을 수 있음을 보여 줍니다.
- 글쓴이는 AI로 버그를 찾는 일이 늘수록 버그를 하나씩 고치기보다 버그 유형 전체를 막는 방어가 중요해진다고 봤습니다.
핵심 내용
- System V 공유 메모리(여러 프로세스가 같은 메모리를 함께 쓰는 기능)의 연결 횟수 카운터가 16비트 부호 있는 정수인 것이 문제였습니다.
- 값이 한계를 넘어 음수가 되는 정수 오버플로가 해제된 메모리를 다시 쓰는 버그(use-after-free)로 이어져, 로컬 사용자가 루트 권한을 얻을 수 있었습니다.
- 이 카운터 정의는 약 37년 전 원래 BSD 소스까지 거슬러 올라갑니다.
- 수정은 OpenBSD 7.9용 패치(errata 026, 018)로 배포됐습니다.
- 글쓴이는 커널 메모리 할당 무작위화, 배열 경계 검사 같은 방어를 도입해 공격 비용을 높이자고 제안했습니다.
HN 반응
- 많이 검토된 코드에서 37년을 버틴 것이 놀랍다는 반응에, 개발자가 적어 생각만큼 검토되지 않는다는 반론과 코드가 작아 읽는 사람이 많다는 재반론이 맞섰습니다.
- 원격이 아닌 로컬 취약점이라 OpenBSD의 원격 취약점 기록과는 무관하다는 지적과, NetBSD는 1999년 재작성 때 우연히 고쳐졌다는 보충이 나왔습니다.
OpenBSD 릴리스 스타일 그래픽, 칭찬합니다. 주제가도 기대할게요.
흥미롭게도 NetBSD에서는 1999년 8월에 해당 코드를 다시 쓰면서 우연히 고쳐진 것 같습니다.
NetBSD가 왕이죠. 지구상에서 가장 이식성 좋은 운영체제입니다(커널만이 아니라 OS 전체가요).
1978년 VAX/780까지 거슬러 올라가는데, x86이든 ARM이든 지금도 하나의 기반 소스에서 그대로 돌아갑니다.
가장 철저하게 감사(audit)받는 코드베이스 중 하나에서 버그가 37년이나 살아남았다는 건 놀랍습니다. 코드 리뷰만으로 잡아내기 힘든 커널 버그가 있다는 걸 보여 주는 것 같고요. 퍼징이나 정적 분석으로 이런 유형의 버그를 현실적으로 찾을 수 있었을까요, 아니면 익스플로잇 프리미티브를 생각하는 사람의 머리가 필요했을까요?
퍼징은 연산이 충분히 많이 반복되지 않기 때문에 오버플로 사례를 잘 잡지 못합니다. 값이 증가하는 것으로 보이는 입력을 다시 돌려 보는 "카운터 탐지" 단계를 퍼즈 엔진에 넣을 수 있지 않을까 싶은데요. 이미 누군가 시도해 봤을 수도 있겠네요.
이 사이트의 블로그 글은 전부 AI가 썼고, 다루는 버그와 익스플로잇도 AI가 찾아낸 것들입니다.
그러니 퍼징이랑 비슷한 셈이죠. 이런 식으로 악용 가능한 게 모든 BSD와 리눅스 시스템에 무섭도록 많이 묻혀 있습니다. 라우터, 자동차, PLC 등 오래된 커널을 돌리는 모든 임베디드 시스템도 마찬가지고요.
AI가 쓴 글도 분명 있습니다. 그런 실용적인 내용이라면 상관없겠죠. 하지만 지금 이 글은 전부 사람이 쓴 걸로 보이는데요.
사람이 쓴 거라 해도 잘 쓴 글은 아닙니다. 익스플로잇 소스를 공개한 건 좋은데, 익스플로잇 설명이 형편없어요. 짧고 간결한 불릿 포인트 일곱 개가 전부입니다. 많이 파헤쳐 보지 않고서는 무슨 일이 벌어지는 건지 분명하지 않아요. 완화책 논의는 그나마 낫습니다.
참고로 저는 대학 수준의 보안 수업을 가르치는데, 학부생들이 스택 스매싱 같은 공격을 해 봅니다(해마다 재능 있는 학생 몇 명은 ROP 공격이나 레이아웃 랜덤화 엔트로피 분석, 사이드 채널 공격 같은 것도 해냅니다). 그 학생들의 리포트는 전부 이 글보다 훨씬 낫습니다.
LLM이 쏟아내는 장황한 말 설사를 늘 상대해야 하는 시대에, 사람이 쓴 글이 너무 간결하다는 게 불만이라면... 간단한 해결책을 알려 드릴게요. LLM한테 시키면 원하는 만큼 몇 페이지고 쓰레기로 늘려 줄 겁니다.
제가 말하고 싶은 핵심은 쓰레기(slop)는 어떤 경우에도 싫다는 겁니다. 사람이 시간을 들여 써야 한다고 생각해요. 솔직히 제 인상은 정반대였습니다. 전형적으로 전문 용어를 남발하는 AI식 불릿 포인트 같았거든요.
버그를 찾는 데 효과적인 도구라면 뭐든 쓰는 건 좋습니다. 하지만 사람 독자가 읽을 거라 기대한다면 사람에게 글을 써 달라고 요구하는 게 무리는 아니잖아요? 버그는 대부분 논리의 결함을 드러내고, 운영체제에서는 그런 논리적 결함이 때로 교훈이 되어 단순한 버그 수정을 넘어 더 나은 설계로 이어지기도 합니다. 그러니 여기서 놓친 기회가 있을 수 있어요.
이 경우에는 사람이 쓴 걸로 보이는데, 그랬더니 이번엔 잘 못 썼다고 불평하셨네요.
뭘 해도 이길 수 없는 상황인가 봅니다.
이길 수 없는 상황이 아닙니다. 사람이라는 것만으로는 충분하지 않다는 거예요! 더 잘 쓰세요! 글 잘 쓰는 사람은 얼마든지 있습니다. 못 쓰는 사람과 잘 쓰는 사람의 가장 큰 차이는, 잘 쓰는 사람은 더 잘 쓰려고 애쓴다는 점입니다.
생각만큼 철저하게 감사받지는 않아요. 활동하는 개발자가 열두 명 정도밖에 안 되거든요.
패치를 리뷰하려면 개발자가 (믿을 수 있는 사람으로) 몇 명이나 필요할까요?
감사 대상은 커널과 기본 유저랜드뿐입니다. 포트(ports)는 훨씬 덜 꼼꼼하게 살펴보고요.
윗글의 요점은 개발자가 부족하다는 게 아니었습니다. 원래 댓글의 "가장 철저하게 감사받는 코드베이스 중 하나"라는 표현이 과장이라는 얘기였어요.
"철저하게 감사받는다"를 다르게 볼 수도 있습니다. 많은 OS와 브라우저 같은 것들은 엄청난 양의 상당히 복잡한 코드를 안고 있다는 문제가 있습니다. 반면 OpenBSD는 코드가 비교적 단순하고 (의도적으로) 양이 적어서 아주 읽기 좋고, 실제로 매일 프로덕션에서 쓰는 범용 운영체제 가운데 꽤 많은 사람이 코드를 읽어 보는 프로젝트 중 하나입니다.
리눅스 커널의 아무 부분이나 OpenBSD 커널, 혹은 덩치 큰 브라우저와 비교해서 이해해 보세요. 완전히 파악한다는 기준으로요. 차원이 다릅니다.
여기서 부차적인 효과가 생깁니다. 사람들이 자기 전문 분야가 아닌 코드도 실제로 들여다보고, 개발자들도 자기 서브시스템 밖에서 작업하게 됩니다.
반면 리눅스만 해도 어딘가 어느 회사의 누군가 한 명만 어느 정도 파악하고 있는 코드가 방대하게 있습니다. 리눅스에서 취약점이 끊임없이 나오는 곳이 바로 거기죠. OpenBSD는 그런 것들을 적극적으로 걷어냅니다. 2014년에 블루투스 지원을 없앤 것도 그 예고요. 그래서 사람들이 실제로 깊이 파고들 수 있는 상황이 됩니다. 켜 둔 안전장치(guardrail)도 엄청나게 많아서, OpenBSD를 대상으로 하지도 않으면서 그 안전장치가 문제를 잡아내 주기 때문에 OpenBSD에서 코드를 컴파일해 보는 사람들도 제가 압니다.
좀 더 큰 소프트웨어 회사를 떠올려 보세요. 자기 팀 바깥에서 돌아가는 일은 전혀 모를 가능성이 큽니다. 어쩌면 자기 팀 일도 다 모르고요.
오픈 소스에서(사실 클로즈드 소스에서도) 우리가 늘 보는 공격 경로가 이런 것들입니다. 브라우저에서 모두가 쓰고 깊이 이해하려 하는 부분이 익스플로잇을 일으키는 게 아닙니다. 표준에 들어 있거나 어쩌다 지원이 추가됐는데 아무도 안 쓰는 작은 부분이 문제입니다. 표준이라서, 혹은 아무도 굳이 없애지 않아서 그냥 남아 있는 거죠.
OpenBSD는 보안을 위해 일부 표준을 깨기로 한 적도 있는데, 그건 다른 얘기고요.
제가 하고 싶은 말은 이겁니다. 개발자도 더 많고 코드를 들여다보는 사람도 더 많은 프로젝트를 얼마든지 떠올릴 수 있지만, 그런 프로젝트는 빠르게 변하는 거대한 코드베이스인 경우가 많아서 아무도 전체를 제대로 이해할 수 없습니다. 어떤 그룹이나 개인이 나타나 그 부분을 집어 들기 전까지는 감사받지 않은 부분이 있을 가능성이 크다는 뜻이죠.
37년이나 묵었다는 점을 보면 이번에도 아마 그런 일이 벌어졌을 겁니다.
OpenBSD를 옹호하려는 게 아니라, 감사 대상의 크기를 고려하지 않으면 사람 수가 별 의미가 없다는 점을 짚으려는 겁니다. 큰 프로젝트야말로 LLM이 진가를 발휘할 분야라고 생각하지만, 코드와 복잡도를 줄여 공격 표면을 줄이는 것이 가장 큰 방어일 수 있다고도 생각합니다. 제가 본 바로는 OpenBSD가 그 점을 아주 잘하고 있고, 다른 프로젝트들이 배울 만한 사례로 봐야 합니다.
그리고 이건 이런 종류의 소프트웨어에만 해당하는 얘기가 아닙니다. 소프트웨어만의 문제도 아니고요. 인프라도 마찬가지여서, 복잡해지면 보통 공격 표면이 늘어납니다. 분명히 해 두면, 복잡도는 늘 더해지기 마련이지만 목표를 이루는 데 필요한 최소한이어야 하고, 정말 신경 쓰지도 유지하고 싶지도 않은 부차적인 목표는 들이지 않으려 해야 합니다.
특히 LLM이 있는 지금은 복잡도를 더하기가 너무나 쉬워서, 내일의 LLM(이나 사람)이 엄청난 양의 버그를 찾아내게 만들 뿐입니다.
불쌍한 OpenBSD 사람들. 이제 홈페이지에 익스플로잇을 (통틀어) 세 개나 인정해야 하네요.
이건 원격 취약점이 아니고(최근에 나온 유일한 로컬 취약점도 아닌 것 같아요), 그러니 아뇨, 문구를 고칠 필요는 없을 겁니다.
내용이 나오기도 전에 AI가 만든 그래픽부터 나오는 건 좀 정이 떨어지네요.