
LXD를 통한 Linux 권한 상승
Linux 시스템에서 로컬 lxd 그룹의 멤버는 루트로 권한을 상승시킬 수 있는 여러 경로를 가지고 있습니다. 이 저장소에는 완전히 자동화된 로컬 루트 익스플로잇의 예제가 포함되어 있습니다. 취약점에 대한 자세한 설명과 익스플로잇 분석은 제 블로그 여기에서 확인할 수 있습니다.
아래 익스플로잇은 컨테이너 탈출이 아니라, 컨테이너를 활용하고 호스트 OS를 공격 대상으로 하는 로컬 루트 익스플로잇입니다. 익스플로잇을 성공시키려면 호스트 환경에 대한 낮은 권한의 접근이 필요합니다.
저는 익스플로잇 버전 2의 전략이 독특하다고 생각하며, 위에 링크된 블로그에서 자세한 설명을 작성할 만큼 흥미로웠습니다.
lxd_rootv1.sh는 호스트의 / 파일시스템을 컨테이너에 마운트하며, 여기서 호스트의 낮은 권한 사용자가 루트 접근 권한을 가집니다. 이 루트 접근은 호스트로 다시 매핑되어 현재 사용자를 /etc/sudoers 파일에 추가할 수 있게 합니다. 이것은 저보다 먼저 다른 사람들에 의해 악용되었습니다.lxd_rootv2.py는 호스트의 systemd 개인 UNIX 소켓을 컨테이너에 마운트한 다음 LXD 프록시 장치를 통해 다시 호스트로 연결합니다. 이 프록시 장치는 루트 권한을 가지며, 소켓 통신 중에 시작하는 낮은 권한 사용자의 자격 증명이 아닌 자신의 자격 증명을 전달합니다. 이를 악용하여 현재 사용자를 /etc/sudoers 파일에 추가하는 임시 systemd 서비스를 생성합니다.두 익스플로잇 모두 컨테이너가 필요하므로 먼저 하나를 만드십시오. 그런 다음 호스트 OS에서 첫 번째 인수로 컨테이너 이름을 지정하여 익스플로잇을 실행합니다.
# v1로 익스플로잇
$ bash lxd_rootv1.sh <컨테이너 이름>
# v2로 익스플로잇
$ python3 lxd_rootv2.py <컨테이너 이름>

제가 이러한 문제를 발견하기 전까지는 lxd 그룹이 위험하다는 경고를 하는 공식 LXD 문서는 존재하지 않았습니다. LXD를 구성하기 위한 공식 지침을 따르는 사람은 첫 번째 컨테이너를 배포하기 전에 자신의 계정을 이 그룹에 추가했을 것입니다. 저는 Canonical에 버그를 제기하여 우려 사항을 전달했습니다. 전체 스레드는 여기에서 읽을 수 있습니다. LXD 팀은 신속하게 문서를 조정했으며, 이제 이 그룹은 루트 접근 권한을 신뢰하는 사람에게만 부여되어야 한다는 점을 명확히 명시하고 있습니다.
언제나 그렇듯이 버그 트래커를 통해 Canonical 직원과 상호 작용하는 것은 정말 즐거운 경험이었습니다. 그들의 시간과 제 아이디어에 대해 신중하게 고려해 주신 점에 감사드립니다. 다른 보안 연구자들도 이와 같은 방식으로 직접 그들에게 사항을 제기하는 것을 강력히 권장합니다.
저는 LXD를 악용한 첫 번째 사람이 아닙니다. 이 문제는 2016년으로 거슬러 올라가는 여러 GitHub 이슈에서 우려 사항으로 제기되었습니다:
첫 번째 링크는 제가 알기로 이 위험을 처음으로 식별한 사람(simpoir)입니다.
@reboare는 제 v1 익스플로잇과 동일한 방법을 사용하여 LXD를 악용하는 훌륭한 블로그를 저보다 훨씬 먼저 작성했습니다:
멋진 도구를 만들어 준 LXD 관계자들에게 감사드립니다. 저는 개인적으로 LXD를 사용하며 정말 좋아합니다. 이것이 LXD 사용에 있어 중대한 결함이라고 생각하지 않으며, lxd 그룹에 사용자를 추가할 때 잠재적인 위험을 이해하는 것이 매우 중요하다고 생각합니다.
이 두 취약점에 대한 공식적인 수정 사항은 없습니다. LXD를 사용하는 모든 사용자는 lxd 그룹에 사용자를 추가하는 것이 본질적으로 그들을 루트로 만드는 것임을 인지해야 합니다.
데스크탑과 같은 단일 사용자 호스트에서 LXD를 사용하는 경우, lxd 그룹을 전혀 사용하지 않고 API와 통신해야 할 때 sudo를 실행하는 것이 가장 좋을 수 있습니다.
여러 사람이 컨테이너로 작업하는 공유 환경에서는 중첩된 환경을 만드는 것이 가장 좋을 수 있습니다. LXD 그룹의 각 사용자는 자신의 환경을 악용할 수 있지만, 그 컨테이너에서 탈출하여 다른 사람을 악용하려면 더 많은 노력이 필요합니다.