CVE-2026-31431 "Copy Fail"...Rootless 컨테이너가 방어선
리눅스 커널의 Copy Fail 취약점이 발견됐지만, Rootless 컨테이너의 격리 구조가 호스트 시스템 침해를 차단한다는 점이 주목받고 있다.
[한국정보기술신문] 리눅스 커널의 새로운 취약점 CVE-2026-31431이 발견되면서 보안 커뮤니티가 긴장하고 있다. 공격자가 암호화 API를 악용하여 시스템 바이너리를 변조할 수 있다는 내용이다. 하지만 Rootless 컨테이너 아키텍처의 방어력이 가장 큰 관심사가 되고 있다.
Copy Fail 취약점의 위험성
이 취약점은 Linux 커널의 암호화 API 중 하나인 AF_ALG 소켓의 문제다. "authencesn(hmac(sha256),cbc(aes))" 암호화 함수의 ESN 스크래치 쓰기 기능을 악용할 수 있다. 공격자는 파일 권한을 우회하여 페이지 캐시에 직접 쓰기를 수행한다. 결과적으로 /usr/bin/su 같은 시스템 바이너리를 악성 ELF 페이로드로 교체할 수 있게 된다.
Rootless 컨테이너의 격리 메커니즘
이 취약점의 영향을 제한하는 핵심은 User Namespace의 UID 매핑이다. Rootless 컨테이너에서는 컨테이너 내부의 UID 0, 즉 루트 권한이 호스트의 낮은 권한 사용자로 매핑된다. 예를 들어 컨테이너 내의 UID 0이 호스트의 UID 1000으로 실행되는 것이다. 따라서 취약점 공격이 성공하더라도 컨테이너 내부의 루트일 뿐이다.
호스트 시스템 침해 방어
가장 중요한 점은 공격이 컨테이너 경계를 넘지 못한다는 것이다. 커널 LPE(Local Privilege Escalation) 공격이 성공해도 실제로는 호스트 시스템에 대한 권한이 없다. 격리된 사용자 네임스페이스 때문이다. 이는 Rootless 아키텍처의 설계 이점을 명확하게 보여준다.
실제 채택 사례
이 보안 이점 때문에 GNOME의 GitLab 러너는 Rootless Podman을 채택하기로 결정했다. 컨테이너 오케스트레이션에서 보안이 점점 더 중요해지고 있기 때문이다. Rootless 컨테이너는 단순한 기술 선택이 아니라 필수적인 보안 전략이 되었다.
보안 아키텍처의 중요성
이 사건은 방어 심화 전략의 필요성을 다시 한 번 보여준다. 단일 방어선에만 의존할 수 없다. User Namespace, cgroups, seccomp 같은 여러 격리 기술이 함께 작동해야 한다. 제로 트러스트 보안 모델에서 이러한 계층적 방어가 얼마나 중요한지를 증명하는 사례다.
한국정보기술신문 정보보안분과 안서진 기자 news@kitpa.org
