요약
아직 고쳐지지 않은 리눅스 커널 취약점 보고 여러 건이 비공개 보안 창구 대신 공개 메일링 리스트에 올라왔습니다.
포로닉스 보도에 따르면 10월 22일 트렌드마이크로의 제로데이 이니셔티브(ZDI)가 보낸 취약점 보고 6건이 리눅스 커널 메일링 리스트(LKML)에 공개됐습니다. 실수로 보이며, 커널 메인테이너 그레그 크로아하트먼이 보고마다 공개 목록에 올릴 생각이었는지 되물었습니다.
왜 중요한가
- 수정이 정식 커널(메인라인)에 들어가기도 전에 취약점 내용이 먼저 세상에 알려졌습니다.
- 가장 심각한 두 건은 원격 코드 실행 문제여서 패치를 앞당겨 넣어야 할 수도 있습니다.
핵심 내용
- 6건은 원격 코드 실행 2건, 로컬 권한 상승(일반 사용자가 관리자 권한을 얻는 문제) 3건, 정보 유출 1건입니다.
- 원격 코드 실행 두 건은 커널에 들어 있는 SMB(파일 공유 프로토콜) 관련 코드에서 나왔습니다.
- 이 두 건의 CVSS(취약점 심각도 점수)는 9.0입니다.
- 일부는 시험 중이거나 다음 버전용 브랜치에 패치가 있지만, 메인라인에 반영된 것은 아직 없습니다.
- 네트워크 코드의 한 건은 지난주 다른 경로로 이미 보고돼 곧 패치가 나올 예정입니다.
HN 반응
- 여러 이용자가 커널 보안 문서에 AI로 찾은 버그는 공개된 것으로 취급하라는 규칙이 있어 단순 실수가 아닐 수 있다고 짚었습니다.
- 같은 버그가 여러 연구자에게서 같은 날 쏟아진 경험에서 나온 규칙이라는 옹호와, 찾을 수 있다고 이미 찾은 것은 아니라는 반론이 맞섰습니다.
AI로 찾아낸 커널 취약점은 공개 메일링 리스트로 제보하라고 리눅스 커널 쪽에서 권장하지 않나요? 제 기억이 맞다면, 같은 취약점에 대한 제보가 여러 건씩 몰려서 보안 메일링 리스트가 마비될 지경이 되자 그 정책을 도입한 걸로 알고 있어요.
언뜻 보면 맞는 말씀입니다.
AI가 사람과 다른 버그를 찾아낸다고 생각한다는 점이 무척 흥미롭네요. AI로 버그를 찾았다면 다른 사람도 같은 버그를 쉽게 찾을 수 있다고 보면서, 직접 찾은 버그는 어쩐지 더 민감한 비밀로 취급한다는 거잖아요.
저는 현실이 그렇게 깔끔하게 나뉜다고 생각하지 않아요.
제가 보기에 그 기대는 LLM으로 버그를 찾았다면 다른 사람도 LLM으로 찾을 테니 어차피 비밀이 아니라는 뜻입니다. LLM으로 찾은 버그는 수동 검토로 발견되지 않는다거나 그 반대라는 말과는 다릅니다.
이 발상은 두 갈래에서 나온 것 같습니다. 첫째, LLM은 비교적 예측 가능해서 같은 프롬프트와 같은 검토 절차를 쓰면 같은 버그를 찾을 가능성이 높습니다. 둘째, 무료나 저가 요금제를 쓰면 대화 내용이 학습 데이터로 흘러 들어가 결국 얼마 뒤에는 LLM이 그 내용을 '아는' 상태가 될 수 있습니다. 후자는 커널 보안팀이 과대평가하고 있는 듯합니다(Greg KH가 이 문제로 한 강연에서는 "LLM이 한 사람에게 버그를 찾아 주고 나면, 버그를 찾는 다른 사람에게도 그걸 넘겨주기로 한다"는 식으로 설명했는데, 내부 동작 방식은 전혀 그렇지 않습니다).
맞아요.
뚜렷한 구분은 아닐 수 있지만 어떤 식으로든 차이가 있을 수 있고, 그게 직관과는 반대일 수도 있습니다.
LLM의 큰 강점은 방대한 컨텍스트 윈도우, 병렬화와 작업 위임 능력, 그리고 집중력이 떨어지거나 잠을 잘 필요가 없다는 점입니다. 함수와 모듈을 무작위로 조합해 가며 악용 가능한 조합이 나올 때까지 하루 종일 생각할 수 있습니다. 사람에게는 어려운 일이고, 그런 종류의 취약점은 다른 LLM 기반 도구가 아니고서는 아마 영영 발견되지 않을 겁니다. 저는 보안 전문가가 아니지만, 이런 AI 취약점은 보통 사람이라면 끈기가 모자라 도저히 뒤져 볼 수 없는 거대한 건초 더미 속의 작은 바늘 같은 것으로 알고 있습니다.
반면 사람이 직접 찾았다면 그만큼 단순하고 움직이는 부품 수가 적어서, 한꺼번에 머릿속에 담고 문제를 알아보고 그 결과를 정확히 추론할 수 있는 버그라는 뜻입니다. 그렇다면 악용하기가 더 쉬울 가능성이 크고, 공개되면 더 위험하다는 이야기가 됩니다.
거꾸로인 것 같기도 하고 실제로 거꾸로일 수도 있지만, 이득이 있다면 이런 맥락일 것 같습니다.
이 정책은 실제로 벌어지는 일을 바탕으로 만들어졌습니다. 리눅스 보안팀에는 AI가 만든 중복 제보가 쏟아졌고, 그래서 중복을 피하려고 AI로 찾은 보안 버그는 공개 메일링 리스트로 제보해 달라고 정책을 바꿨습니다. 사람이 찾은 버그에서는 아직 그런 일이 없었으니 기존 정책이 그대로 유지되고 있고요. 앞으로 어느 시점에는 AI가 찾는 버그가 사람이 찾는 버그를 모두 포함하는 상위 집합이 될 가능성이 높지만, 지금은 사람과 AI가 잘 찾는 버그의 종류가 서로 다른 것 같습니다. 그런 날이 오면 AI가 항상 먼저 찾아내니 사람이 찾는 버그는 점점 줄어 사라질 테고, 정책 변경은 저절로 해결될 겁니다.
“AI의 도움을 받아 버그를 찾아냈다면 그 버그는 공개된 것으로 취급해야 합니다. 그렇지 않다고 믿을 만한 타당한 이유가 있더라도, 보안팀의 경험상 이런 방식으로 발견된 버그는 여러 연구자에게서 체계적으로, 종종 같은 날 동시에 드러납니다. 이 경우 재현 코드는 의도치 않은 피해를 낳을 수 있으므로 공개적으로 공유하지 말고, 재현 코드가 있다는 사실만 언급하세요. 필요하다면 메인테이너가 비공개로 요청할 것입니다.”
재현 코드를 공개적으로 공유하지 말라는 건 곧 AI가 찾은 버그라는 뜻이네요.
아니요, 버그 자체와 문제의 코드 위치는 공유하라는 겁니다. 버그를 악용하는 코드, 즉 재현 코드를 공개적으로 공유하지 말라는 거예요. 그 부분은 작성하기가 훨씬 어려운 경우가 많은데, 그 코드가 있어야 그 버그가 실제로 악용 가능하다는 게 증명되고, 악용도 안 되는 그냥 버그가 아니라는 게 확인됩니다.
유효한 보안 문제라면 AI는 그리 큰 걱정거리가 아니라고 봅니다.
그걸 AI로 찾았는지 아닌지에는 사실 아무도 신경 쓰지 않을 겁니다. 버그 자체의 무게가 다른 우려를 압도해야 하니까요. 전문 보안 업계는 그렇게 돌아갑니다. 버그에 대한 우려야 늘 이래저래 있기 마련이고, 무엇이 더 무거운가에 따라 공개 절차의 방향이 정해집니다.
유효한 보안 버그라면 그 자체만으로도 기술적 무게가 충분하니, AI로 찾았는지 여부에 대한 우려는 의미가 없어져야 합니다.
어쨌든 리눅스 쪽 사람들은 컴퓨터 보안에 별로 신경 쓰지 않는 것 같아요. 인프라와 관련 보안 문제에는 더 신경 쓰겠거니 생각하고 싶긴 해요. 내 컴퓨터가 활짝 펼쳐진 책이나 다름없다면, 그걸 둘러싼 보안 문제가 무슨 상관이겠어요?
아무튼...
여기까지만 하죠 ㅋㅋ
그건 이 정책의 취지가 아니에요.
정책의 논리는, 내가 AI로 찾았다면 다른 사람들도 AI로 얼마든지 쉽게 찾을 수 있다는 거예요. 그래서 AI로 찾은 버그는 처음부터 공개된 것으로 취급하는 거고요.
제 속에 있는 음흉한 면이 이런 생각을 하게 되네요. AI로 찾았는데 알고 보니 환각이라면 AI 출력을 제대로 검증하지 않은 대가로 공개적인 망신을 감수해야 하니, 그것도 이유 중 하나가 아닐까 하고요.
제가 아는 한, 대부분의 오픈소스 프로젝트에서 보안은 신경 쓰는 문제가 아니에요.
다만 이런저런 이유로, 흥미롭다고 생각한 취약점에는 공로를 인정해 줄 수도 있겠죠.
지금은 리눅스 커널 이야기를 하고 있잖아요. 그들이 보안을 신경 쓰지 않는다고 말할 만한 근거라도 있나요?
리눅스 커널 메인테이너들은 보안을 대하는 방식이 좀 주류와 거꾸로 가는 편입니다. 무엇보다 버그를 보안 영향도에 따라 분류하고 순위를 매기는 일에 저항하고, 대신 거의 모든 버그가 똑같이 중요하니 보안을 유지하고 싶다면 그냥 최신 버전으로 주기적으로 업데이트하라고 고집합니다.
오픈소스 리눅스는 한때의 유행일 뿐이고, 리누스는 작은 막대기로 발가락을 좀 맞아야 하니까요.
정말 유치하네요.
당연히 그래야죠. LLM이 찾아냈다면 다른 LLM이나, 같은 LLM을 돌리는 다른 사람도 찾을 수 있다고 봐야 합니다. 사실상 이미 공개된 거나 마찬가지예요.
아니요. 저도 LLM이 있지만 그걸 발견하진 못했어요. 인사팀 사람들도 LLM은 있지만 당신 같은 소프트웨어를 만들어 내진 못하고요. LLM이 발견할 수 있다고 해서 아직 발견됐다는 뜻은 아닙니다. 책임 있는 공개(responsible disclosure)는 여전히 가치 있는 일이에요.
지금 LLM을 커널에 들이대면서 보안 버그를 찾고 계신가요?
이 정책은 즉흥적으로 만든 게 아니에요. 리눅스 보안팀의 말을 인용하면 이렇습니다. "이런 방식(AI)으로 발견된 버그는 여러 연구자에게서 체계적으로, 종종 같은 날 동시에 드러납니다."
'책임 있는 공개'라는 말은 벤더들이 지어낸 헛소리예요.
그런 논리면 메인테이너들이 직접 LLM을 커널에 돌려 보면 되니까 제보할 이유가 아예 없다고도 할 수 있겠네요.
이런 버그를 찾아낼 만한 방식으로 LLM을 커널에 적극적으로 들이대고 있진 않아요. 그리고 가능하다고 해서 이미 일어난 일이라는 뜻은 아니고요.
좋아요, 그럼 동시에 나오는 것들은 그렇게 나오도록 두면 되죠. 그게 심각도와 상관없이 LLM이 발견에 관여했다는 이유만으로 취약점을 곧바로 공개하는 것과 무슨 상관이 있나요?
그런 의견을 가지시는 건 자유지만, 책임과 공개가 서로 무관한 개념이라고 주장하시는 게 아니라면 그 의견이 제가 한 말과 무슨 상관인지 모르겠네요.
아직 눈이 침침한 상태로 보긴 했는데, 가장 심각한 것들은 SMB와 KSMBD에 있고, 이게 커널 공간에 구현되어 있는 모양입니다. KMB를 쓰지 않는 사람에게는 영향이 없을 것 같아요.
나머지는 LPE인데, 두 개는 이미 삭제돼서 자세한 내용은 확인할 수 없습니다.
TrendMicro 사이트를 열면 "Advancing AI-Native Security with Anthropic"이라는 큼지막한 문구가 맨 위에 뜹니다. 뭐, 앞뒤가 맞긴 하네요.
망신을 주려면 제목에 Trend Micro 이름을 넣어야죠. 아마추어같이.
시뮬레이션의 이번 시즌 참 볼만하네요
매 에피소드가 클리프행어예요.
https://hackerone.com 의 공개 절차는 완전히, 그리고 대놓고 공개적이니 저는 놀랍지 않습니다.
하지만 그쪽도 협력 대상 제품에서 Linux는 빼 놓은 상태예요.
여러분은 AI 덕분에 버그 없는 OS 배포판이나 프로그래밍 언어, 그러니까 일종의 완벽함 같은 걸 이루게 될 거라고 생각하세요?
코드를 쓰는 것만으로는 아니죠.
그럼 질문은 모든 걸 검사하게 강제하고 버그를 허용하지 않는 형식 검증 언어 같은 걸 만들 수 있느냐가 되겠네요. 어쩌면요?
하지만 그것도 밑바탕의 하드웨어와 펌웨어에 그 가정을 깨뜨릴 결함이 없다는 전제에서의 이야기예요.
그건 버그를 한 층 위로, 그러니까 검증 대상이 되는 명세로 옮길 뿐이에요.
맞아요, 하지만 훨씬 표면적이 작잖아요(P != NP를 믿는다면 일반적인 경우 점근적으로도 더 작고요).