들어가며: 2026년의 안정 속에 남은 2024년의 경각심
안녕하세요, codingrich.com의 여러분. 2026년 3월 16일, 현재 우리는 도커(Docker)와 쿠버네티스를 비롯한 컨테이너 기술이 매우 성숙한 단계에 진입했습니다. 그러나 기술의 발전과 함께 보안 위협 또한 끊임없이 진화하고 있습니다. 오늘은 2년 전인 2024년 초, 컨테이너 보안 역사상 가장 충격적인 사건 중 하나로 꼽히는 ‘Leaky Vessels(누수하는 그릇)’ 취약점 사태를 되짚어보고, 이 사건이 현재 2026년의 보안 환경에 남긴 영향을 분석해 드리고자 합니다.
‘Leaky Vessels’의 등장과 그 파장
2024년 1월 31일, 보안 전문 기업인 Snyk는 도커 컨테이너의 핵심 런타임인 runc와 Docker BuildKit 등에서 발견된 심각한 보안 취약점 그룹을 공개하며 ‘Leaky Vessels’라는 이름을 붙였습니다. 이 사건은 단순한 버그 수정을 넘어, 컨테이너 격리(Isolation) 메커니즘의 근본적인 신뢰를 흔든 사건으로 기록됩니다. Snyk의 보고서에 따르면, 이 취약점들은 공격자가 컨테이너를 탈출하여 호스트 시스템의 권한을 얻을 수 있는 결정적인 경로를 제공했습니다.
취약점의 핵심: CVE-2024-21626과 runc의 결함
이번 사태의 주역은 CVE-2024-21626입니다. 이 취약점은 도커가 사용하는 OCI 표준 런타임인 runc의 내부 작동 방식(CLI 인터페이스 처리)을 악용했습니다. 공격자는 컨테이너 내부에서 WORKDIR과 같은 특정 명령어를 조작하여, 컨테이너가 시작되는 과정에서 파일 디스크립터(File Descriptor)를 유출시킬 수 있었습니다.
구체적으로, runc는 프로세스를 생성할 때 작업 디렉터리를 변경하는 과정에서 /proc/self/fd/와 같은 시스템 경로를 참조합니다. 공격자는 이를 이용해 호스트 시스템의 파일 시스템에 접근할 수 있는 경로를 컨테이너 내부에 남겨두는 데 성공했습니다. 이는 마치 창문을 통해 안쪽에서 밖의 잠금장치를 조작할 수 있는 구멍을 만든 것과 같습니다.
공격 시나리오와 위험도 분석
당시 GitHub 보안 어드바이저리에서는 이 취약점의 심각도를 최고 수준인 CVSS 10.0으로 평가했습니다. 공격자가 이미 컨테이너 내부에서 코드 실행 권한을 가지고 있다고 가정할 때, 이 취약점을 통해 호스트의 루트 권한(root)까지 탈취할 수 있기 때문입니다.
- 호스트 파일 시스템 접근: 컨테이너 밖의 임의의 파일을 읽거나 쓸 수 있습니다.
- 악성코드 실행: 호스트 시스템에서 악성 바이너리를 실행하여 전체 서버를 장악할 수 있습니다.
- 클라우드 환경 위협: 멀티테넌트 환경에서 다른 사용자의 데이터에 접근할 수 있는 치명적인 위험이 있었습니다.
당시 개발자들의 비상 대응과 패치 현황
Leaky Vessels 취약점이 공개되자 전 세계 개발자와 DevOps 엔지니어들은 비상에 돌입했습니다. 특히 이 취약점은 runc 1.1.0 이상의 버전에서 영향을 받아, 최신 버전을 사용하고 있던 시스템일수록 더 큰 위험에 노출되었습니다.
도커(Docker)와 리눅스 재단의 즉각적인 조치
Docker 팀은 즉시 보안 업데이트를 발표했습니다. Docker 공식 블로그는 이 문제를 해결하기 위해 Docker Engine 24.0.7 및 23.0.14 버전을 릴리스했으며, Docker Desktop 사용자들에게도 즉각적인 업데이트를 권고했습니다. 또한, runc 팀 역시 runc v1.1.12 버전을 통해 해당 취약점을 패치했습니다.
당시 상황에서 가장 중요했던 점은 ‘컨테이너 이미지를 재빌드해야 하는가’에 대한 논의였습니다. 다행히 이 취약점은 런타임 환경(runc)의 문제였으므로, 호스트의 Docker Engine이나 runc만 최신 버전으로 업데이트하면 기존의 이미지를 재빌드하지 않아도 보안 위협을 완화할 수 있었습니다. 이는 개발자들에게 큰 안도감을 주었던 부분이었습니다.
2026년 현재, 이 사건이 남긴 유산
시간이 흘러 2026년이 된 지금, Leaky Vessels 사건은 단순히 ‘지난 날의 해킹 사고’가 아닌, 컨테이너 보안 설계의 중요한 교훈으로 남아 있습니다. 현재의 쿠버네티스 1.36 버전과 최신 도커 환경에서는 이러한 파일 디스크립터 유출 문제를 근본적으로 차단하는 보안 강화책들이 기본적으로 탑재되어 있습니다.
특히, Rootless Docker나 User Namespace와 같은 기술의 도입이 가속화되었습니다. 2024년 이전에는 편의성 때문에 루트 권한으로 컨테이너를 실행하는 경우가 많았으나, Leaky Vessels 이후 권한 분리(Privilege Separation)는 선택이 아닌 필수가 되었습니다. 또한, CI/CD 파이프라인에 컨테이너 이미지 스캔을 포함하는 것이 당연시되는 문화가 정착되었습니다.
핵심 요약
- 2024년 ‘Leaky Vessels’ 사태: runc 및 Docker BuildKit에서 발견된 취약점(CVE-2024-21626 등)으로 컨테이너 탈출이 가능했습니다.
- 기술적 원인: runc의 작업 디렉터리 처리 과정에서 파일 디스크립터가 유출되어 호스트 시스템 접근이 가능해졌습니다.
- 대응: Docker Engine과 runc의 즉각적인 패치로 해결되었으며, 이미지 재빌드 없이 런타임 업데이트로 대응 가능했습니다.
- 2026년의 영향: Rootless 컨테이너 실행과 권한 분리가 업계 표준이 되었으며, 런타임 보안에 대한 경각심이 크게 높아졌습니다.
지난 2년간 컨테이너 보안 기술은 눈부시게 발전했지만, 해커들의 공격 기법 또한 진화하고 있습니다. Leaky Vessels 사건은 우리에게 ‘완벽한 보안은 없으며, 끊임없는 점검과 업데이트만이 살 길’이라는 교훈을 남겼습니다. codingrich.com을 통해 앞으로도 여러분에게 중요한 기술 뉴스를 빠르게 전달해 드리겠습니다.
답글 남기기