새로운 Linux Kernel 기능으로 새로운 공격 표면 확보

Linux Kernel은 수년에 걸쳐 그 범위와 기능이 성장해 왔습니다. 새로운 스케줄러, 새로운 드라이버, 새로운 파일 시스템, 새로운 통신 프로토콜, 새로운 보안 허점... 아, 잠깐만요. 마지막 보안 취약점은 다른 것과는 다릅니다. 사실 새로운 보안 허점은 새로 추가된 기능으로 인해 발생하는 경우가 많습니다. 물론 모든 새로운 기능이 새로운 보안 취약점을 추가하는 것은 아니지만, 예상치 못한 모호하고 난독화된 상호 작용이 발생하기 쉬운 방대한 코드베이스와 관련된 보안 취약점은 위험한 상황을 초래할 수 있습니다.

기능은 어떻게 추가되나요?

모든 Kernel 서브시스템은 언젠가 누군가에게 충분히 유용해서 Kernel 메인라인 코드베이스에 포함되도록 제출된 적이 있습니다. 전부는 아니더라도 대부분의 서브시스템은 Kernel 내부가 아닌 사용자 공간에서 구현될 수 있지만, 이러한 코드를 제출하는 사람의 궁극적인 목표는 가능한 모든 성능을 확보하는 것입니다. Kernel 실행 공간에 직접 들어가면 컨텍스트 전환이 줄어들고, 다른 방법으로는 도달할 수 없는 메모리 영역에 직접 액세스할 수 있으며, 일반적으로 다른 핵심 기능 및 하드웨어 액세스에 대한 호출이 더 쉽고 빨라집니다.

수년에 걸쳐 파일 시스템 지원(현재 Kernel에서 바로 지원되는 파일 시스템이 수십 가지에 달함), NTFS, exFAT, XFS 등 다양한 파일 시스템이 확산되었으며, 모두 Kernel에 포함되어야 하는 강력한 이유가 있습니다. 패킷 필터링 모듈, 네트워크 프로토콜도 마찬가지입니다. 그 외에도 수많은 코드가 제출되고, 검토되고, 향후 포함을 위해 다시 작성되고 있습니다(ZFS 아시나요?). 특정 시스템에서 실제로 얼마나 많은 파일시스템이 필요할까요?

Kernel 내부에 디버깅을 제공하는 여러 기능이 존재하므로 디버깅도 마찬가지입니다. 때로는 서로 경쟁하기 때문에 동시에 활성화할 수 없는 경우도 있습니다.

이와 비슷합니다:

(https://xkcd.com/927/)

그래서 무엇이 문제일까요?

Linux Kernel이 시작되었을 때 인터넷은 지금과 비교하면 먼지 한 톨에 불과했습니다. 네트워크에 연결된 시스템의 수와 전 세계의 전체 네트워크를 비교적 쉽게 집계하고 나열할 수 있었습니다. 여러분이 정기적으로 접속하는 시스템을 운영하는 운영자의 이름 정도는 알고 있었을 것입니다. 사이버 보안은 존재하지 않았습니다.

따라서 Kernel에 새로운 기능을 추가함으로써 프로젝트의 범위가 넓어지고 훌륭한 소프트웨어의 도달 범위가 길어졌으며, 사용자 기반이 크게 확장되어 프로젝트가 상당한 규모에 도달했을 때 프로젝트를 이끄는 핵심적인 Linux 애호가 그룹이 형성되었습니다.

누군가에게 새롭고 흥미로운 것을 포함하지 않을 이유가 많지 않았습니다. 오히려 그 반대의 경우, 기능이 많을수록 사용자들의 관심도 높아졌습니다.

상황이 바뀌었습니다. 사실 꽤 많이 바뀌었습니다.

수하물을 문 앞에 맡기세요

결과적으로 복잡한 코드를 여러 개 추가하면 점점 커지는 무언가에 예기치 않은 결과를 초래하는 경우가 있습니다.

버클리 패킷 필터(BPF) 하위 시스템을 예로 들어보겠습니다. 처음에 새로운 맞춤형 방화벽 구현을 추가하기 위한 방법으로 고안되고 제안된 이 서브시스템은 사용자가 기본적으로 모든 코드를 추가하고 Linux Kernel 실행 컨텍스트에서 실행할 수 있게 해줍니다. 또한 지난 몇 년 동안 수십 개의 취약점, 그중에는 꽤 심각한 취약점의 원인이기도 합니다. 그 목적을 감안하면 전혀 예상치 못한 일은 아닙니다.

다른 위험 요소는 명확하게 구분되지 않습니다.

다른 예를 들어보겠습니다. 작년에 ksmbd 서브시스템이 제안되어 Kernel에 채택되었습니다. 이 서브시스템은 Samba와 다소 유사합니다(즉, 별도의 소프트웨어에 의존하지 않고 SMB 파일 공유를 직접 사용할 수 있게 해준다는 점). 궁극적으로는 더 짧은 호출 스택 깊이(Samba처럼 Kernel ABI를 통하지 않고 Kernel 함수를 직접 호출)에 의존하여 더 빠른 SMB 전송 속도를 제공해야 합니다. 취약성, 웜, 익스플로잇 및 기타 끔찍한 이야기로 점철된 SMB의 역사를 알면 우려할 만한 이유가 있을 수 있지만, 삼성의 후원을 받아 Kernel로 넘어갔습니다. 물론 사이버 보안이 그렇듯이 며칠 전에는 공개적으로 다음과 같은 사실이 공개되었습니다. KSMBD에 10점(10점 만점)의 위험 취약점이 존재한다는 사실이 공개되었습니다.Kernel 5.15 코드 베이스(예를 들어 Ubuntu 22.04에서 사용)에 존재한다는 사실이 공개되었습니다.

단순히 새로운 기능만 추가하는 것이 아닙니다. 안타깝게도 프로덕션 시스템에서만 발견되는 버그와 새 코드와 기존 코드 간의 예기치 않은 상호 작용을 모두 추가하고 있습니다.

크리스마스를 위한 또 하나의 석탄 덩어리

따라서 작년의 악명 높은 Log4j와 마찬가지로 연말연시 시즌은 매우 위험한 취약점이 생겨나기 좋은 시기입니다. 시스템 관리자와 보안팀이 Log4j를 파악하고 제때 패치를 적용하는 데 어려움을 겪었던 것처럼, 이 새로운 ksmbd 취약점도 지금 패치를 적용하지 않으면 해킹당할 수 있는 또 다른 취약점입니다. 원격으로 익스플로잇할 수 있고, 쉽게 트리거할 수 있으며, 전체 시스템 액세스 권한을 부여합니다. 지금까지는 사용자가 공유에 대한 인증을 받아야만 실행할 수 있는 것으로 밝혀졌기 때문에 다행스러운 소식이지만 여전히 심각한 문제입니다. "지금 패치하라"는 말은 과소평가입니다.

또한, IT 팀이 스켈레톤 크루를 운영하며 대응 속도가 느릴 때 새로운 취약점이 발견되는 이유는 무엇일까요? 아, 잠깐만요...

근본 원인 고려 사항

이 글은 특정 하위 시스템에 대한 비판이 아닙니다. Kernel 자체나 개발 프로세스에 대한 비판도 아니며, 성공은 부인할 수 없는 분명한 사실입니다. 하지만 항상 "하지만"이 있듯이 새로운 하위 시스템은 더 오래 테스트에 머물러야 할 수도 있습니다. 또는 이미 사용자 공간에서 유사한 기능을 구현할 수 있는 경우 Kernel 포함을 아예 허용하지 않아야 할 수도 있습니다. 모든 요청에는 항상 설득력 있는 이유가 있으며, 이는 항상 빵을 자른 후의 '차선책'입니다. 속담에 나오는 악마는 이 경우 (구현) 세부 사항에 있습니다.

보안 환경이 점점 더 위험해지고 있는 것처럼 새로운 시스템을 받아들이기 위한 요건을 강화해야 할 때일지도 모릅니다. 결국, 사물을 주시할 수 있는 눈은 한정되어 있습니다.

Kernel에는 수십만 줄의 코드가 있으며, 아주 새로운 코드와 초창기부터 남아 있는 낡은 부분 사이의 이상하고 아름다운 상호작용을 모두 설명할 수는 없습니다. 거의 사용되지 않는 스케줄러가 있는 시스템에서 새로 추가되는 파일 시스템이 퓨즈를 끊지 않을 것이라고 누가 장담할 수 있을까요? 테스트 스위트가 이를 설명할 수 있을 정도로 좋은가요? 아니면 다가오는 휴가철에 IT 팀을 놀라게 할 또 다른 돌발 상황이 기다리고 있을까요?

저 역시 크리스마스 기간 동안 해커가 시스템에 침입할까 걱정하지 않고 에그노그를 즐길 수 있었으면 좋겠습니다.

요약

기사 이름

새로운 Linux Kernel 기능으로 새로운 공격 표면 확보

설명

Linux Kernel은 수년에 걸쳐 그 범위와 기능이 성장해 왔습니다. 새로운 스케줄러, 새로운 드라이버, 새로운 파일 시스템, 새로운 통신 프로토콜, 새로운 보안 허점

작성자

조아오 코레이아

게시자 이름

TuxCare

게시자 로고