LXD 제한 프로젝트 우회: 스냅샷 복원이 여는 호스트 root 명령 실행 경로

스냅샷을 서버 사이에서 옮길 수 있다는 점은 운영 편의를 주는 기능입니다. Canonical이 공개한 보안 권고는 바로 그 성질이 제한 프로젝트의 경계를 뚫는 통로가 될 수 있다고 경고합니다.

개요

Canonical은 LXD의 restricted project 기능과 관련해 'Restricted project bypass leading to arbitrary command execution'이라는 제목의 권고를 GitHub 보안 어드바이저리에 공개했습니다. 논지는 단순합니다. 스냅샷은 서버 간 이동이 가능하므로, 로컬에서 악의적인 인스턴스와 스냅샷을 만들어 제한 프로젝트로 옮기고 그 스냅샷을 복원하면 임의 명령 실행에 이를 수 있다는 것입니다.

권고는 결과도 명시합니다. 실제로는 악의적인 행위자가 호스트에서 root 권한으로 임의 명령을 실행할 수 있다는 것입니다. 프로젝트에 제한이 걸려 있어도, 스냅샷 복원이라는 한 지점에서 호스트 전반의 신뢰 경계를 다시 살펴야 한다는 뜻입니다.

실제 환경에서의 악용은 제공된 자료로 확인되지 않았습니다. 무엇이 확인되고 무엇이 확인되지 않는지는 아래 기술적 분석의 공개 PoC·익스플로잇 분석 항목이 근거의 범위대로 가립니다.

영향 범위

핵심 대상은 프로젝트 단위로 제한을 걸어두면서도 인스턴스와 스냅샷을 옮기고 복원하는 경로를 열어둔 LXD 환경입니다. 제한 프로젝트라는 이름 자체가 방어선으로 여겨지던 구성이므로, 확인 작업은 권한 목록만 보는 데서 시작하기보다 스냅샷의 유입과 복원 경로를 보는 편이 맞습니다.

• 외부에서 가져온 스냅샷을 제한 프로젝트 안에서 복원할 수 있는 구성
• 스냅샷이 서버 사이를 이동할 수 있는 능력을 유지한 채 제한 프로젝트를 운용하는 구성

버전 정보는 두 곳에서 확인됩니다. LXD 리포지토리의 보안 권고 API 응답은 patched_versions, 즉 수정 버전으로 6.9, 5.21.5, 5.0.7을 표시합니다. GitHub Advisory Database의 같은 GHSA 항목에는 Go 패키지 버전 문자열 0.0.0-20260630083100-c5184be310b1이 first_patched_version, 즉 최초 수정 버전으로 표시되어 있습니다.

한계는 그 바깥에 있습니다. 각 지원 계열에서 취약 범위가 어디까지 이어지는지, 즉 계열별 영향 상한이 몇인지는 전달된 발췌로 확인할 수 없고, 배포 채널의 패키지에 이 수정이 반영되었는지도 같은 이유로 확인되지 않습니다. 따라서 우리 환경이 어느 계열에 속하는지를 특정한 뒤, 위 수정 버전과 비교하고 배포 채널 패키지까지 확인하는 단계는 별도 작업으로 남습니다.

같은 제목의 별개 권고(Incus 보안 어드바이저리)를 공개한 Incus는 별개 제품입니다. 이 글은 Incus의 설명을 LXD의 사실로 옮기지 않습니다.

기술적 분석

확인되는 공격 경로

권고가 그리는 경로는 세 동작으로 요약됩니다. 로컬에서 악의적인 인스턴스와 스냅샷을 만들고, 그것을 제한 프로젝트로 옮긴 뒤, 옮겨진 스냅샷을 복원합니다. 여기서 결정적인 성질은 스냅샷이 서버 간에 이동할 수 있다는 점이고, 권고는 이 이동성을 전제로 경로를 설명합니다. 각 단계에 필요한 구체적 권한이나 추가로 요구되는 조건은 전달된 자료로 확인되지 않아, 진입 조건을 정확한 권한 조합으로 확정해 옮겨 적을 수는 없습니다.

복원이 저수준 실행으로 이어진다는 점이 이 경로를 단순한 설정 우회로 남겨두지 않습니다. 도달 지점이 프로젝트 안의 격리된 인스턴스가 아니라 호스트의 root 명령 실행이기 때문에, 제한 프로젝트를 신뢰 경계의 종점에서 검토해야 합니다.

저수준 원인은 어디까지 말할 수 있는가

Incus 권고는 메커니즘을 구체적으로 서술합니다. 인스턴스 스냅샷이 restricted.containers.lowlevel=block 설정을 무시하고, raw.lxc와 raw.qemu 같은 저수준 훅을 악용해 Incus 서버에서 임의 명령 실행이 가능하다는 설명입니다.

이 서술은 가능한 형태의 하나를 보여줄 뿐입니다. LXD에서 같은 훅이 관여하는지, 어떤 저수준 경로가 차단 설정을 비켜가는지, 공격자가 인스턴스와 스냅샷을 로컬에서 제작할 때 필요한 권한은 무엇인지는 전달된 자료로 확인되지 않았습니다. Incus의 설명을 LXD의 확인된 원인으로 단정하지 않습니다.

원인이 확인되지 않았다는 사실은 점검 범위의 위치를 바꿉니다. 스냅샷 복원이 호스트 권한 실행으로 이어질 수 있다면, 검토 단위는 프로젝트에 부여된 권한 집합에서 스냅샷을 들여오고 복원할 수 있는 사람과 경로로 이동합니다.

공개 PoC·익스플로잇 분석

출처. 이 항목이 참조할 수 있는 근거는 네 건입니다. Canonical의 LXD 보안 어드바이저리는 위의 공격 경로와 호스트 root 명령 실행이라는 결과를 진술하고, 같은 GHSA 항목의 LXD 리포지토리 보안 권고 API 응답과 GitHub Advisory Database 레코드는 patched_versions와 first_patched_version이라는 버전 값을 담고 있습니다. 마지막 하나인 Incus 보안 어드바이저리는 별개 제품의 메커니즘을 설명합니다. 전달된 범위에는 LXD의 스냅샷 복원 절차와 호스트 root 실행이라는 결과를 진술하는 근거와, 수정 이력을 기록한 버전 레코드, 그리고 별개 제품의 메커니즘 서술이 함께 놓여 있습니다.

전제조건. 근거가 진술하는 전제는 확인되는 공격 경로에 정리한 권고의 동작 기술, 즉 스냅샷의 서버 간 이동성과 제작·이동·복원이라는 세 동작까지입니다. 그 바깥의 권한 요구나 추가 전제는 확인되지 않았으므로, 이 글은 공격 성립 조건을 권한 조합으로 확정해 쓰지 않습니다.

입증 범위. 입증 범위는 권고가 진술하는 경로와 결과에까지 이르고, 그 바깥으로는 확장되지 않습니다. Incus 권고의 훅 설명은 별개 제품의 메커니즘 서술이므로 LXD의 입증 자료로 취급하지 않으며, 버전 값의 patched_versions와 first_patched_version 표기는 수정 이력을 알려줄 뿐 악용 상태를 알려주지 않습니다. 실제 환경에서의 악용 여부를 알려주는 항목은 전달된 자료에 없습니다. 따라서 이 항목이 확정하는 것은 호스트 root 명령 실행까지 이어지는 경로 그 자체이고, 실제 악용 여부는 확인되지 않은 상태로 남습니다.

운영상 의미. 초점은 악용 증거의 유무가 아니라 경로의 유무로 이동합니다. 악용이 확인되지 않았다는 사실을 근거로 점검을 늦추기보다, 권고가 설명하는 이동 및 복원 경로가 우리 환경에 열려 있는지 먼저 확인하는 편이 합리적입니다. 반대로 추가적인 공개 재현물이 확인되어야만 대응에 착수할 수 있는 것도 아닙니다. 탐지 규칙이나 침해 지표는 제공된 자료에서 확인되지 않았으므로, 그 미확인 상태를 전제로 점검 항목을 정하는 편이 안전합니다.

대응 방안

즉시 점검

가장 먼저 볼 것은 제한 프로젝트 안에서 인스턴스와 스냅샷을 옮기고 복원할 수 있는 경로가 열려 있는지입니다. 관리 콘솔, API, 클라이언트 권한, 프로젝트 위임 설정을 막론하고 스냅샷이 유입되는 지점과 복원이 일어나는 지점을 함께 찾아 정리해야 합니다. 로컬 제작 단계에 필요한 권한은 확인되지 않았으므로, 점검 결과로 얻은 조건만으로 안전을 결론내리지는 않는 편이 좋습니다.

같은 흐름에서 다음으로 볼 일은 신뢰할 수 없는 스냅샷을 구분하는 것입니다. 복원 작업을 검토할 때 호스트 root 권한 실행 가능성을 전제로 두고, 외부에서 유입된 스냅샷과 내부에서 제작된 스냅샷을 구분해 다루는 것이 합리적입니다. 어떤 속성으로 신뢰를 판별할지에 대한 기준은 제공된 자료에 없습니다.

로그와 감사 범위 점검

탐지는 관측 가능성 점검에서 시작합니다. 관련 인스턴스와 스냅샷의 이동 및 복원 활동이 현재 로그나 감사 범위에 잡히는지 먼저 확인해야 합니다. 특정 로그 항목이나 침해 지표는 전달된 근거에서 확인하지 못했으므로, 이 글에서 지표 이름을 새로 만들지 않았습니다.

수정 버전 확인과 장기 대응

구조적 처리는 공식 권고 확인에서 출발합니다. LXD 리포지토리의 보안 권고 API가 patched_versions로 6.9, 5.21.5, 5.0.7을 표시하는 만큼, 우리 배포 환경이 어떤 계열에 속하는지를 먼저 특정하고 해당 계열의 수정 버전과 비교하십시오. GitHub Advisory Database의 같은 GHSA 항목이 0.0.0-20260630083100-c5184be310b1을 first_patched_version으로 표시한다는 사실도 확인되지만, 그 표기 자체는 레코드가 담고 있는 진술의 범위입니다. 이 문자열이 어떤 빌드나 배포 단위를 가리키고 우리 환경의 구성과 어떻게 대응되는지는 전달된 자료로 확인되지 않아, 이를 곧바로 Go 패키지를 사용하는 환경의 수정 여부 판정 기준으로 삼을 수는 없습니다. 여기서 별도로 확인해야 할 것은 각 계열의 영향 상한과, 배포 채널 패키지에 이 수정이 실제로 반영되었는지, 그리고 위 버전 문자열이 우리 환경에 어떤 의미인지입니다. 이 항목은 공식 권고 원문과 배포 채널 확인으로 마무리해야 합니다. Incus를 함께 운용하는 환경이라면 Incus 권고의 저수준 차단 설정과 훅 관련 설명을 별도 항목으로 검토할 수 있습니다.

참고자료

• Restricted project bypass leading to arbitrary command execution
• LXD repository security advisory API — affected versions
• Restricted project bypass leading to arbitrary command execution
• GitHub Advisory Database — GHSA-47w9-6r3f-938g

함께 읽으면 좋은 글

• CVE-2026-124424: AVideo AI 플러그인의 자막 경로 순회 취약점 점검
• CVE-2026-123498: Vikunja veans 코딩 에이전트 지시문으로 들어가는 프로젝트 메타데이터
• CVE-2026-121792: GamiPress의 Gravity Forms 연동에서 발견된 SQL 인젝션

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.