sofianehamlaoui/cve-2022-0492-checker컨테이너 환경이 CVE-2022-0492를 통한 컨테이너 탈출에 취약한지 확인하는 스크립트
컨테이너 환경이 CVE-2022-0492를 통한 컨테이너 탈출에 취약한지 확인하는 스크립트
2월 4일, _Linux_는 커널의 새로운 권한 상승 취약점 CVE-2022-0492를 발표했습니다.
CVE-2022-0492는 컨테이너의 기본 구성 요소인 Linux 기능인 제어 그룹(cgroups)의 논리적 버그를 나타냅니다. 이 문제는 최근 발견된 가장 간단한 Linux 권한 상승 중 하나로 두드러집니다: Linux 커널이 권한이 없는 사용자에게 권한이 필요한 작업을 실수로 노출했습니다.
다행히도 대부분의 컨테이너 환경에서 기본 보안 강화 조치만으로도 컨테이너 탈출을 방지하기에 충분합니다. AppArmor 또는 SELinux를 사용하여 실행되는 컨테이너는 보호됩니다. 즉, 모범 사례 강화 없이 컨테이너를 실행하거나 추가 권한을 부여하는 경우 위험에 처할 수 있습니다. "영향을 받습니까?" 섹션은 취약한 컨테이너 구성을 나열하고 컨테이너 환경이 취약한지 테스트하는 방법에 대한 지침을 제공합니다.
컨테이너 외에도 이 취약점은 기능이 없는 루트 호스트 프로세스 또는 CAP_DAC_OVERRIDE 기능이 있는 비 루트 호스트 프로세스가 권한을 상승시키고 모든 기능을 획득할 수 있도록 할 수 있습니다. 이로 인해 공격자가 특정 서비스에서 사용하는 강화 조치를 우회할 수 있으며, 이는 손상 발생 시 영향을 제한하기 위해 기능을 제거합니다.
CVE-2022-0492는 이제 악성 컨테이너가 탈출할 수 있도록 하는 최근 몇 개월간의 세 번째 커널 취약점입니다. 세 가지 취약점 모두에서 Seccomp와 AppArmor 또는 SELinux로 컨테이너를 보호하는 것으로 컨테이너 탈출을 방지하기에 충분했습니다.
cgroupfs를 마운트하려면 현재 cgroup 네임스페이스를 호스팅하는 사용자 네임스페이스에서 CAP_SYS_ADMIN 기능이 필요합니다. 기본적으로 컨테이너는 CAP_SYS_ADMIN 없이 실행되므로 초기 사용자 네임스페이스에서 cgroupfs를 마운트할 수 없습니다. 그러나 unshare() syscall을 통해 컨테이너는 새로운 사용자 및 cgroup 네임스페이스를 생성하여 CAP_SYS_ADMIN 기능을 보유하고 cgroupfs를 마운트할 수 있습니다.
그림 1 - CAP_SYS_ADMIN 기능을 가질 새로운 사용자 네임스페이스를 생성하는 컨테이너.
모든 컨테이너가 새로운 사용자 네임스페이스를 생성할 수 있는 것은 아닙니다. 기본 호스트에 권한 없는 사용자 네임스페이스가 활성화되어 있어야 합니다. 예를 들어 최근 Ubuntu 릴리스에서는 이것이 기본값입니다. Seccomp가 unshare() syscall을 차단하므로 Seccomp 없이 실행되는 컨테이너만 새로운 사용자 네임스페이스를 생성할 수 있습니다. 첨부된 스크린샷에 표시된 컨테이너는 Seccomp, AppArmor 또는 SELinux 없이 실행됩니다.
그림 2 - 컨테이너가 새로운 사용자 및 cgroup 네임스페이스에서 메모리 cgroup을 마운트합니다.
위 스크린샷에서 컨테이너가 메모리 cgroup을 성공적으로 마운트했지만 마운트된 디렉터리에 release_agent 파일이 포함되지 않은 것을 확인할 수 있습니다!
앞서 언급했듯이 release_agent 파일은 루트 cgroup에서만 표시됩니다. cgroup 네임스페이스에서 cgroupfs를 마운트할 때의 한 가지 단점은 루트 cgroup이 아닌 자신이 속한 cgroup을 마운트한다는 것입니다.
그림 3 - 컨테이너가 새로운 사용자 및 cgroup 네임스페이스에서 루트 RDMA cgroup을 마운트합니다.
문제를 악용하려면 악성 릴리스 에이전트를 release_agent 파일에 작성해야 합니다. 위의 그림 3에서 볼 수 있듯이 해당 파일은 root가 소유하므로 root 컨테이너 프로세스만 릴리스 에이전트를 설정할 수 있습니다. 그림 4는 컨테이너가 릴리스 에이전트를 설정하는 모습을 보여주고, 그림 5는 비 root 컨테이너가 실패하는 모습을 보여줍니다.
그림 4 - root 컨테이너가 릴리스 에이전트를 설정합니다.
그림 5 - 비 root 컨테이너는 릴리스 에이전트를 설정할 수 없습니다.
탈출의 마지막 단계는 구성된 release_agent를 호출하는 것으로, 어떤 권한도 필요하지 않습니다. 이 단계는 항상 수행 가능하므로 환경이 CVE-2022-0492에 취약한지 여부에 영향을 미치지 않으므로 생략하기로 결정했습니다. 아래 스크린샷에서 전체 익스플로잇이 어떻게 생겼는지 확인할 수 있습니다.
그림 6 - 사용자 네임스페이스를 통해 CVE-2022-0492를 악용하여 컨테이너 탈출.
새로운 사용자 및 cgroup 네임스페이스를 생성하는 대신 컨테이너에 CAP_SYS_ADMIN 기능이 부여된 경우 더 간단한 익스플로잇이 가능합니다. CAP_SYS_ADMIN 기능으로 실행되는 컨테이너는 질문 없이 cgroupfs를 마운트할 수 있습니다. 추가로, 오늘날 대부분의 컨테이너는 cgroup 네임스페이스 없이 실행되므로 마운트된 cgroup은 루트 cgroup이 되고 release_agent 파일도 함께 제공됩니다.
그림 7 - 초기 cgroup 네임스페이스에서 cgroupfs를 마운트하면 컨테이너의 cgroup과 관계없이 항상 루트 cgroup이 마운트됩니다.
CAP_SYS_ADMIN 기능이 있더라도 AppArmor 및 SELinux는 여전히 마운트를 차단하므로 둘 중 하나를 사용하는 컨테이너는 CVE-2022-0492를 악용할 수 없습니다. 그림 8은 AppArmor 및 SELinux 없이 실행되고 CAP_SYS_ADMIN 기능을 가진 컨테이너가 CVE-2022-0492를 악용하여 탈출하는 모습을 보여줍니다.
그림 8 - CAP_SYS_ADMIN 기능을 통해 CVE-2022-0492를 악용하여 컨테이너 탈출.
CVE-2022-0492는 컨테이너 탈출에 악용될 수 있는 또 다른 Linux 취약점입니다. 다행히도 모범 사례를 따르는 환경은 이 취약점으로부터 보호됩니다. 느슨한 보안 제어로 신뢰할 수 없거나 공개적으로 노출된 컨테이너를 호스팅하는 환경은 당연히 높은 위험에 처해 있습니다. 항상 그렇듯이 호스트를 수정된 커널 버전으로 업그레이드하는 것이 가장 좋습니다.
이 취약점과 향후 Linux _제로데이 취약점_으로부터 보호하기 위해 Seccomp와 AppArmor 또는 SELinux 중 하나를 활성화하여 컨테이너를 실행하는 것을 강력히 권장합니다. Linux 커널의 많은 권한 상승 취약점은 컨테이너가 새로운 사용자 네임스페이스를 생성할 수 있거나, 즉 컨테이너가 Seccomp 없이 실행될 때만 컨테이너 탈출에 악용될 수 있습니다.
© 2022 - 아님 Sofiane Hamlaooui - 세상을 더 나은 곳으로 만들기 🌎
