격리된 컨테이너에서 탈출을 허용하는 cgroups v1의 취약점

커널의 cgroups v1 리소스 제한 메커니즘 구현에서 발견된 취약점(CVE-2022-0492)에 대한 세부 정보가 공개되었습니다. Linux이는 격리된 컨테이너에서 탈출하는 데 사용할 수 있습니다. 문제는 커널부터 나타나기 시작합니다. Linux 2.6.24 버전에서 발생했던 문제가 커널 릴리스 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 및 4.9.301에서 수정되었습니다. 각 배포판의 패키지 업데이트 릴리스는 다음 페이지에서 확인할 수 있습니다. Debian, 수세, UbuntuRHEL, Fedora, Gentoo, Arch Linux.

이 취약점은 전체 권한으로 핸들러를 실행할 때 적절한 검사를 수행하지 못하는 release_agent 파일 핸들러의 논리 오류로 인해 발생합니다. release_agent 파일은 cgroup의 프로세스가 종료될 때 커널이 실행할 프로그램을 정의하는 데 사용됩니다. 이 프로그램은 루트 이름 공간의 모든 "기능"을 사용하여 루트로 실행됩니다. release_agent 설정은 관리자만 접근할 수 있다고 가정했지만 실제로는 루트 사용자에게 접근 권한을 부여하는 것으로 제한되어 있어 컨테이너에서 설정이 변경되거나 관리자 권한이 없는 루트 사용자(CAP_SYS_ADMIN)가 설정을 변경하는 경우도 제외되지 않았습니다. ).

이전에는 이러한 기능이 취약점으로 인식되지 않았으나, 컨테이너의 루트 사용자와 겹치지 않는 별도의 루트 사용자를 컨테이너에 생성할 수 있는 사용자 네임스페이스(사용자 네임스페이스)의 출현으로 상황이 바뀌었습니다. 주요 환경. 따라서 공격의 경우 별도의 사용자 ID 공간에 자체 루트 사용자가 있는 컨테이너에 release_agent 핸들러를 연결하는 것으로 충분하며, 프로세스가 완료된 후 기본 환경의 전체 권한으로 실행됩니다.

기본적으로 cgroupfs는 읽기 전용 모드로 컨테이너에 마운트되지만, CAP_SYS_ADMIN 권한이 있거나 unshare 시스템 호출을 사용하여 별도의 사용자 네임스페이스가 있는 중첩 컨테이너를 생성하면 쓰기 모드에서 이 pseudofs를 다시 마운트하는 데 문제가 없습니다. 생성된 컨테이너에 대해 CAP_SYS_ADMIN 권한을 사용할 수 있습니다.

이 공격은 격리된 컨테이너에서 루트 권한으로 수행하거나, 추가 권한 부여를 방지하는 no_new_privs 플래그 없이 컨테이너를 실행할 때 수행할 수 있습니다. 시스템에서 사용자 네임스페이스가 활성화되어 있어야 합니다(기본적으로 활성화됨). Ubuntu Fedora에서도 사용 가능하지만 활성화되어 있지는 않습니다. Debian RHEL을 포함한 다양한 운영체제에서 사용 가능한 루트 cgroup v1에 대한 접근 권한이 필요합니다(예: Docker는 루트 RDMA cgroup에서 컨테이너를 실행합니다). CAP_SYS_ADMIN 권한을 사용해도 공격이 가능하며, 이 경우에는 사용자 네임스페이스 지원 및 루트 cgroup v1 계층 구조에 대한 접근 권한이 필요하지 않습니다.

격리된 컨테이너에서 탈출하는 것 외에도 취약점은 "기능"이 없는 루트 사용자 또는 CAP_DAC_OVERRIDE 권한이 있는 사용자가 시작한 프로세스도 허용합니다(공격을 위해서는 /sys/fs/cgroup/*/release_agent 파일에 대한 액세스가 필요합니다. 루트 소유) 모든 시스템적 "기능"에 액세스할 수 있습니다.

참고로, Seccomp, AppArmor 또는 SE 보호 메커니즘을 사용하는 경우에는 해당 취약점을 악용할 수 없습니다.Linux 컨테이너의 추가적인 격리를 위해 Seccomp는 unshare() 시스템 호출을 차단하고 AppArmor 및 SE도 마찬가지입니다.Linux cgroupfs를 쓰기 모드로 마운트하는 것을 허용하지 마십시오.

출처 : opennet.ru