커널에서 권한 상승 취약점이 천 개씩 나오는 지경에 어떻게 이르렀을까? 커널이 너무 복잡해져서 논리적으로 검토하기 어려운 걸까, 아니면 보안 모델이나 구현 언어의 근본적인 결함일까?
다른 모든 소프트웨어는 커널보다 더 취약하다고 가정해야 할까?
다들 자신이 관심 있는 문제로 연결하려 하지만, 시스템이 복잡하고 최첨단 AI 모델의 해킹 능력이 인간을 넘어섰다는 것만으로 충분히 설명 가능해 보임.
LoRa 칩인 LR2021을 다루면서 개발 보드를 컴퓨터에 연결하고 Claude에게 역공학을 시켰는데, 분석 속도와 효율이 믿기 어려울 정도였음. 몇 시간 만에 제조사 전용인, 내부가 전혀 알려지지 않은 패치 RAM 영역에 맞춤 패치를 작성하기 시작함. 자세한 내용은 여기에 적어둠. https://beala.substack.com/p/your-node-doesnt-need-a-microco....
Linux 개발에 자금을 대고 사용하는 대기업들이 보안보다 속도를 중시하기 때문임. 속도를 내려면 빠르게 실행할 코드를 커널에 많이 넣어야 함.
권한 상승 취약점이 천 개씩 나오지 않는 작고 검증하기 쉬운 커널도 있지만, 상당히 느림. 많은 용도에서는 괜찮지만 대규모 데이터센터에서는 1%만 느려져도 서버 비용이 수백만 달러 늘어날 수 있음.
OpenBSD는 Unix 보안 모델에서도 이런 취약점을 크게 줄일 수 있음을 보여주지만, 약 10% 느림. 기업에는 연간 수백만 달러의 추가 비용이고, 일부 소프트웨어는 io_uring이나 eBPF처럼 OpenBSD가 보안상 허용하지 않는 기능도 요구함. seL4도 대안이지만 느리기는 마찬가지임.
결국 서버 비용과 해킹 피해 비용 사이의 사업적 절충에서 서버 비용이 우선되는 셈임.
다른 소프트웨어가 커널보다 더 취약하다고 봐야 하느냐면, 확실히 그렇다고 봄. 현관문은 늘 열려 있었고, 그동안은 취약점 탐색의 경제성이 개발자에게 유리했을 뿐인데 이제는 달라짐.
살펴보는 곳마다 문제가 나옴. 지난 15년간 엣지 시스템의 사용자 경험은 거의 달라지지 않았는데, 반도체 제조 기술의 발전을 CHERI 같은 보호 계층에 쓰고 성능 향상 속도를 조금 늦출 수도 있었을 것임. 대신 보안은 조금만 개선하고 사용자가 거의 체감하지 못하는 기능을 주로 추가함.
장기적으로는 정형 검증에 기대를 걸지만, 사람이 증명 명세를 검토하고 원하는 속성과 일치하는지 확인하는 체계를 갖추려면 오랜 시간이 필요함. AI를 이용한 해킹은 당장 시급하므로 단기적으로는 구현부터 증명 명세와 증명 작성까지 AI에 맡겨야 할 듯함. 잘될 수도 있지만 결과는 알 수 없음.
이 업계를 알아온 내내 권한 상승 버그는 흔하다는 것이 일반적인 전제였음. 보안이 그런 버그가 없다는 가정에 의존한다면 보안이 없는 것이나 마찬가지라는 이야기도 오래전부터 반복돼 왔음.
불편한 진실은 다중 사용자 환경이 1990년대에 사실상 죽었고, 이후로는 권한 상승도 기본적으로 가능한 일로 취급해 왔다는 것임.
집에서 석면을 발견한 것처럼 씁쓸하면서도 다행인 결과임. 모르는 것보다는 낫지만 애초에 없었으면 훨씬 좋았을 것임.
과거 시점의 스냅샷으로 작업했다고 이해했는데, 새 PR이 들어올 때마다 지속적으로 검사해서 새로운 취약점이 추가되는 것을 막을 계획도 있는지?
모델이 발전하면서 더 정확한 결과를 더 많이 내놓게 되면, 무엇을 신뢰하고 어디에 사람의 검토가 필요한지 어떻게 결정하는지 궁금함. 948건이면 대규모 팀이나 수개월의 검토 기간 없이는 신속하게 확인하기 어려운 분량임.
수정: 더 읽어보니 답이 있었음. 모든 보고서를 수동 조사하기는 어려워, 낮은 권한으로 접근 가능하고 특별한 권한이 필요 없으며 메모리 손상의 측정 가능한 증거가 있는 항목에 검증을 집중했다고 함.
오래된 코드에서도 로컬 권한 상승 취약점이 나왔을 것으로 짐작함. Linux Foundation에는 Google 모델로 커널의 각 커밋에서 버그와 취약점을 분석하는 Sashiko(https://sashiko.dev/)가 있는데, 이번에 찾은 취약점 중 Sashiko도 발견한 것은 몇 개인지?
프로그래머가 아니라 변경 기록만으로 커널에서 무슨 일이 벌어지는지 이해하기 어려워 질문함. 단순히 개별 패치를 하는 대신, 비슷한 문제가 재발하지 않도록 구조적으로 해결하고 있는지?
같은 유형의 결함이 다른 하위 시스템에도 있을 수 있다고 보고 체계적으로 모두 수정하는 식으로, 교훈을 문서화하고 적용하고 있는지도 궁금함.
코드의 나이와 커널 영역별로 나눈 결과를 보고 싶음. 드라이버, 네트워킹, 코어 등으로 구분하면 좋겠음.
이 취약점들에다 목록에 없는 취약점까지 분명 존재할 텐데, 인터넷은 어떻게 아직 돌아가는 걸까? 전기는 왜 들어오고 발전소는 왜 수십 곳씩 폭발하지 않는 걸까?
이 정도의 취약성이 인류의 존립을 위협하지 않도록 막는 요인은 무엇일까?
지난 한 달에만 PHP 취약점 때문에 여러 정부가 주요 온라인 서비스를 중단해야 했고, 해킹된 냉장고에서 수백만 달러어치 식품이 가열돼 EU 7개국의 식량 공급에 차질이 생김. 아직 존립 위협 수준은 아니지만 그쪽으로 가는 듯함.
컴퓨터 시스템, 특히 네트워크로 연결된 시스템이 신뢰하기 어렵다는 것은 1980년대부터 알려져 있었음. 사이버보안 업계 전체가 침입 자체를 막기보다는 불가피하게 발생한 침입의 피해를 빠르게 줄이는 방식으로 운영됨.
이런 자동 취약점 탐색·패치 작업이 소프트웨어의 신뢰성을 크게 높여, 별도의 사이버보안이 필요 없어지기를 바람.
이 글에 대한 Sidero Labs의 생각이 궁금하며, 그들의 노력에 기대를 걸고 있음. 이제 단일 용도만 지원하는 곳이 아님. Talos OS는 독립형 서버 OS, 하이퍼바이저 서버나 클러스터, 주력인 Kubernetes 노드나 클러스터로 모두 사용 가능함.
이 모든 것을 GitOps에 바로 활용할 수 있는 불변 OS로 제공하니, 거의 마음이 기운 상태임.
Linux에서는 늘 일반 사용자 접근 권한이 있으면 거의 확실히 root도 얻을 수 있다고 생각해 왔음. 그래도 취약점 948개는 꽤 충격적임. 좋아지기 전에 더 나빠지는 시기가 이제 끝나가기를 바람.
이 부분에서는 Windows가 유리하다고 봄. ACL과 기능별 권한을 갖춘 AppContainer 등이 10년 넘게 OS에 내장돼 있었음.
Windows에도 로컬 권한 상승 취약점은 많음. 단일 사용자 운영체제로 출발했고, 소프트웨어가 항상 관리자 권한으로 실행되지 않도록 바뀌는 데도 오랜 시간이 걸렸다는 점을 기억해야 함.
최신 패치가 적용되지 않은 OS의 낮은 권한 계정이, 자원이 풍부한 공격자에게는 사실상 root 접근과 같다고 당분간 봐야 한다니 외면하고 싶고 눈물이 날 지경임.
로컬 권한 상승이 워낙 흔해서, 이제 잠재적으로 악성인 소프트웨어를 격리하는 데 낮은 권한의 사용자 계정을 쓰지 않음. 이는 시스템을 무너뜨리려는 공격자가 아니라, 규칙을 지키는 사용자의 접근을 통제하는 용도로만 쓰임.
일반 Paxos와 비잔틴 Paxos의 차이가 떠오름.
자율적으로 취약점을 발견·악용·패치하는 파이프라인으로, 한 번 실행해 Linux 로컬 권한 상승 취약점 948개를 검증하고 패치하는 데 API 비용 120만 달러가 들었다고 함.
Linux Foundation이나 아마 Mozilla 말고도, 다른 오픈소스 단체들이 보안에 이만큼의 LLM API 사용료를 쓸 수 있다면 어떨까?
자본이 접근을 제한하는 모든 분야에 해당하는 이야기임. 모든 대학이 전파망원경, 입자가속기, 양자컴퓨팅 연구실을 이용할 수 있다면 어떨까? 거대한 데이터센터에서 돌아가는 최첨단 모델은 공동 자원이 소수에게 독점되는 새로운 거대 범주임.
실제 연구 결과라기보다 점점 마케팅 자료가 돼 가는 듯함. OpenAI도 모델을 더 똑똑하게 만드는 데 한계에 부딪혔지만 뉴스에서 존재감을 유지해야 하는 것 아닐까? Google이 법률 같은 특정 분야에 모델을 특화하려는 것과 비슷해 보임. Sol 6.1의 추론 성능이 너무 나빴는데, 모델 자체가 형편없거나 이런 홍보에 자원을 몰아주느라 실제 사용자에게는 뒤에서 품질을 낮춘 결과를 주는 것 같음. 이런 일을 멈추고 더 나은 모델을 만들거나 물러났으면 함. 적어도 그러면 RAM이 저렴해져 가중치 공개 모델의 발전에 도움이 될 것임.