안녕하세요! 컨테이너 기술의 세계를 항해하는 여러분들을 위해, 오늘은 도커(Docker)의 역사에 깊은 상처와 교훈을 남겼던 가장 치명적인 보안 취약점(CVE) 세 가지를 되짚어보는 시간을 갖고자 합니다. 🐳
컨테이너 기술은 애플리케이션을 격리하여 독립된 환경에서 실행할 수 있게 해주는 혁신적인 기술이지만, 이 격리된 성벽이 무너질 때의 위험성은 상상 이상입니다. 여기 소개할 세 가지 취약점은 단순한 버그를 넘어, 컨테이너와 호스트 시스템의 경계를 허물며 우리에게 큰 경각심을 일깨워주었습니다.

🥇 1. 컨테이너 탈출의 대명사: CVE-2019-5736 (RunC 호스트 바이너리 덮어쓰기)
가장 악명 높고, 또 가장 큰 충격을 주었던 취약점을 꼽으라면 단연 CVE-2019-5736을 빼놓을 수 없습니다. 이 취약점은 컨테이너 런타임의 핵심 구성 요소인 runc의 허점을 파고들어, 컨테이너가 호스트 시스템의 runc 바이너리를 덮어쓰고 루트(root) 권한을 탈취할 수 있게 했습니다. 😱
공격 시나리오 💣
- 악성 컨테이너 실행: 공격자가 특수하게 조작된 악성 이미지를 사용하여 컨테이너를 생성하거나, 이미 실행 중인 컨테이너에 접근(docker exec)합니다.
- runc 바이너리 핸들 획득: 컨테이너 내부에서 docker exec 같은 명령이 실행되면, 호스트의 runc 프로세스가 컨테이너 내부로 들어와 작업을 수행합니다. 이때 공격자는 /proc/self/exe 심볼릭 링크를 통해 호스트에 있는 runc 바이너리의 파일 디스크립터(File Descriptor)를 교묘하게 탈취합니다.
- 바이너리 덮어쓰기: 공격자는 획득한 파일 디스크립터를 이용하여 호스트의 runc 바이너리를 악성 코드로 덮어써버립니다.
- 루트 권한 탈취: 이후 호스트에서 다른 사용자가 해당 runc를 사용하여 docker exec 명령을 실행하는 순간, 덮어써진 악성 코드가 호스트에서 루트 권한으로 실행됩니다. 이로써 컨테이너 탈출이 완벽하게 성공하는 것입니다.
이 취약점은 컨테이너가 호스트를 직접 감염시킬 수 있다는 사실을 명확히 보여주었으며, 모든 컨테이너 관리자와 개발자들에게 컨테이너 런타임 자체의 보안 중요성을 각인시킨 결정적인 계기가 되었습니다.
🥈 2. 커널의 허점을 파고든 공격: CVE-2016-5195 (Dirty COW)
"Dirty COW"라는 별명으로 더 유명한 CVE-2016-5195는 사실 도커 자체의 취약점이라기보다는 리눅스 커널의 오랜 버그였습니다. 하지만 이 취약점은 컨테이너의 격리 환경을 무력화하고 호스트에 영향을 줄 수 있었기에 도커 생태계에 큰 파장을 일으켰습니다. 🐮🔥
공격 원리 ⚙️
Dirty COW는 리눅스 커널의 메모리 관리 시스템에서 발생하는 경쟁 상태(Race Condition) 취약점입니다. Copy-On-Write(COW) 메커니즘의 허점을 이용하는데, 메모리에 매핑된 읽기 전용(read-only) 파일을 수정하려고 할 때, 아주 짧은 순간 동안 쓰기 권한을 얻을 수 있었습니다.
컨테이너 내부의 일반 사용자가 이 취약점을 이용하면, 컨테이너에 마운트된 호스트의 읽기 전용 파일(예: /etc/passwd 같은 중요한 시스템 파일)을 수정할 수 있었습니다. 이를 통해 컨테이너 내부에서 권한을 상승시키거나, 심지어는 호스트 시스템의 루트 권한을 얻는 것도 가능했습니다.
도커 컨테이너는 호스트와 커널을 공유하기 때문에, 커널의 취약점은 곧바로 컨테이너의 보안 위협으로 이어질 수 있다는 사실을 명백히 보여준 사례입니다. 이는 컨테이너 이미지뿐만 아니라, 컨테이너가 실행되는 호스트 커널의 버전을 항상 최신으로 유지하는 것이 얼마나 중요한지 일깨워주었습니다.
🥉 3. 기본을 놓쳤을 때의 위험: CVE-2019-5021 (Alpine Linux 루트 계정 Null 패스워드)
마지막으로 소개할 취약점은 코드의 복잡한 허점이 아닌, 기본적인 설정 실수가 얼마나 치명적인 결과를 낳을 수 있는지 보여주는 사례입니다. 경량 리눅스 배포판으로 많은 도커 이미지의 기반이 되는 알파인 리눅스(Alpine Linux)에서 발견된 CVE-2019-5021입니다. 🔑
문제점 😲
무려 3년이 넘는 기간 동안, 공식 알파인 리눅스 도커 이미지의 **루트(root) 계정 패스워드가 빈 값(NULL)**으로 설정된 채 배포되었습니다. 만약 이 이미지 기반의 컨테이너가 PAM(Pluggable Authentication Modules)과 같이 시스템의 shadow 파일을 인증에 사용하는 서비스를 실행하고 있었다면, 공격자는 아무런 암호를 입력하지 않고도 컨테이너의 루트 계정으로 로그인할 수 있었습니다.
컨테이너 내부의 루트 권한을 탈취당하는 것은 그 자체로도 심각한 문제입니다. 공격자는 해당 컨테이너에서 실행 중인 애플리케이션을 완전히 제어하고 데이터를 탈취하거나, 이를 발판 삼아 다른 네트워크로 공격을 확장하는 등의 추가적인 악성 행위를 할 수 있습니다.
이 사건은 아무리 가볍고 최적화된 이미지라도 기본적인 보안 설정이 얼마나 중요한지, 그리고 공식 이미지라고 해서 무조건 신뢰해서는 안 되며 항상 검증이 필요하다는 교훈을 남겼습니다.
마치며 🚀
오늘 살펴본 세 가지 취약점은 각각 런타임의 허점, 공유 커널의 위험, 이미지 설정의 중요성이라는, 컨테이너 보안의 핵심적인 세 가지 축을 상징적으로 보여줍니다. 도커와 컨테이너 기술은 계속해서 발전하고 있지만, 과거의 실수는 언제나 우리에게 중요한 가르침을 줍니다.
안전한 컨테이너 환경을 구축하기 위해 항상 최신 버전의 도커 엔진과 런타임을 사용하고, 호스트 커널을 업데이트하며, 신뢰할 수 있는 베이스 이미지를 사용하되 스스로 보안 설정을 검증하는 습관을 들이는 것이 중요합니다.
여러분의 컨테이너 여정이 항상 안전하기를 바랍니다! 🛡️
'일반IT > IT보안' 카테고리의 다른 글
| 🛡️ 안전한 웹 개발을 위한 시큐어코딩 가이드 (1) | 2025.08.21 |
|---|---|
| 🚨 웹 개발자 필독! 최신 침해 사고 사례로 알아보는 보안 위협 동향 (0) | 2025.08.21 |
| 당신의 도커 이미지는 안전한가요? 🧐 Dockerfile 보안 취약점 완벽 정복 가이드 (0) | 2025.08.20 |
| 🌐 우리나라에서 Web-WAS-DB 인프라를 분리해야 하는 이유: 법적 근거와 기술적 중요성 (1) | 2025.08.19 |
| CCTV 없는 집, 도둑이 들어도 모른다! OWASP A10:2017 - 불충분한 로깅 및 모니터링 (4) | 2025.08.16 |