Copilot을 루팅한 방법
(research.eye.security)- 2025년 4월, Copilot Enterprise에 실시간 Python sandbox(Jupyter Notebook 기반)가 업데이트되어 백엔드 코드 실행이 가능해짐
- Jupyter Notebook의 %command 문법을 통해 기저 시스템에서 임의 코드 실행이 쉬웠으며, 리눅스 명령어도 ubuntu 사용자(miniconda 환경) 로 실행 가능함
- /app/miniconda/bin 경로가 ubuntu 사용자에게 쓰기 가능하고, root의 $PATH에도 우선순위로 잡혀 있어 pgrep 등 주요 명령어를 덮어쓸 수 있는 보안 취약점이 존재함
- 이를 악용해 root 권한을 획득했지만, 컨테이너 내부는 철저히 격리되어 컨테이너 탈출 불가, 추가 정보 유출도 없었음
- 해당 취약점은 4월 보고 후 7월에 중간 위험도로 패치, 보상 없이 리서처 명단에만 등재됨
Microsoft Copilot Enterprise Jupyter Sandbox 취약점 분석
Copilot Enterprise Jupyter 환경 개요
- 2025년 4월부터 Copilot Enterprise에 Jupyter Notebook 기반 Python sandbox가 도입됨
- 사용자는 Jupyter의 %command 문법을 통해 리눅스 시스템 명령어 실행 가능
- 환경은 miniconda 기반 ubuntu 사용자 권한으로 실행, sudo 바이너리는 없음
- 환경 변수, 네트워크, 파일 시스템, 프로세스 정보 등 다양하게 탐색 가능
컨테이너 내부 동작 및 구조
- Copilot은 ChatGPT sandbox와 유사하지만 최신 커널, Python 3.12 사용
- 주요 프로세스: Jupyter Notebook, Go로 작성된 goclientapp (port 6000에서 실행), httpproxy 등
- 네트워크는 loopback과 제한적 link-local 인터페이스만 활성화
- 파일 시스템은 OverlayFS로 /legion 경로를 기반, /app에 커스텀 스크립트 존재
다운로드 및 파일 조작
- 텍스트/커맨드 출력 파일은 정상 다운로드 가능, 바이너리 파일은 손상 위험 있어 base64 인코딩 필요
- 파일은 /mnt/data에 위치하며, blob URL 형태로 외부 다운로드 링크 생성
goclientapp/httpproxy 구조
- goclientapp: 외부에서 /execute 엔드포인트로 받은 코드(JSON 포맷)를 Jupyter 환경에서 실행, 결과 반환
- httpproxy: Jupyter에서 외부로 나가는 HTTP 트래픽을 프록시(ENABLE_EGRESS=false로 비활성화 상태)
entrypoint.sh 스크립트 취약점
- 컨테이너의 진입점 스크립트인 entrypoint.sh에서, 여러 서비스(goclientapp, httpproxyapp)는 ubuntu 사용자 권한으로 실행
- keepAliveJupyterSvc.sh만 root로 계속 실행됨
- 28번째 줄에
pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888"
명령이 $PATH 내 디렉터리 우선순위에 따라 동작 -
/app/miniconda/bin
이 root와 ubuntu 사용자 모두의 PATH에서/usr/bin
보다 앞서 있음 → pgrep 같은 명령을 임의로 대체 가능
루트 권한 획득 과정 및 한계
- 공격자는
/app/miniconda/bin
에 악의적인 pgrep 스크립트를 생성해, entrypoint.sh가 root 권한으로 주기적으로 이 파일을 실행하게 만듦 - 해당 스크립트는 /mnt/data/in 파일을 읽어 쉘 명령으로 실행 후, /mnt/data/out에 결과를 저장
- 이 방식으로 컨테이너 내 root 권한 획득에는 성공했으나, /root 파일 등 민감 정보, 로그 등은 접근 불가, 컨테이너 탈출도 불가능
- 컨테이너는 각종 breakout 시나리오가 모두 패치되어 있었음
마이크로소프트 대응 및 결과
- 2025년 4월 18일: Eye Security에서 MSRC에 취약점 리포트
- 2025년 7월 25일: 마이크로소프트에서 중간 위험도(moderate severity) 로 분류, 패치 후 이슈 종료 및 리서처 명단 등재 (버그바운티 지급 없음)
참고 및 부록
-
Eye Security는 유럽 기반의 사이버보안 기업으로 24/7 위협 모니터링, 인시던트 대응, 사이버 보험 등 제공
-
이 취약점을 포함한 내부 Microsoft 서비스(Entra OAuth 등) 침투 사례는 BlackHat USA 2025 발표 예정
-
타임라인
- 2025년 4월 18일 – MSRC에 보고
- 2025년 7월 25일 – 패치 및 케이스 종료, 블로그 게시
Hacker News 의견
- 이 취약점의 핵심은, 원래 컨테이너 내부에서 일반 사용자 권한만 부여하려던 설계에서 트릭을 이용해 루트 권한으로 코드 실행이 가능했던 것임을 이해함. 그러나 실제로는 컨테이너 자체가 워낙 철저히 격리되어 있어서, 네트워크 접근도 못 하고 탈출도 불가능했기 때문에 루트 권한으로 할 수 있는 게 본인 컨테이너 망가뜨리는 것밖에 없었음
- Microsoft가 정말 철저하게 보안 설정했음을 인정함. 대다수 기업들은 이 정도로 완벽히 격리하지 않음
- 이 컨테이너가 정확히 어떻게 구현되었는지 모르겠음. Microsoft가 Python 샌드박스를 격리하기 위해 표준 방식(Azure container-apps session)을 쓰고 있는데, 이 기능도 그걸 사용하거나 유사한 방식이었길 바람
- Copilot이 어떤 때는 코드 실행을 거부하고, 어떤 때는 허용하는 게 좀 이상하게 느껴짐. 정확히 어디까지 목표로 하고 있는 건지 궁금함
- 요즘엔 취약점이 하나의 스택처럼 쌓이기 때문에 “컨테이너가 안전하다”는 말은 공격자가 아직 취약점을 못 찾았을 뿐이라는 의미임. 컨테이너 탈출이나 VM 탈출도 이미 알려진 공격 방식이고, 설정 실수나 virtio 드라이버에 버그 같은 작은 실수 하나로도 뚫릴 수 있음. 이 사례는 실제로 중요한 결과임
- “How We Rooted Copilot” 같은 제목을 보고 실제 Copilot의 핵심 VM을 뚫은 건 줄 알았는데, 실상은 엄청나게 제한된 파이썬 샌드박스 컨테이너에서 루트 권한을 얻은 것일 뿐임. 더 정확한 제목은 “How We Rooted the Copilot Python Sandbox”가 맞음
- “완전히 격리된 샌드박스에서 일반 사용자에서 루트로 권한 상승에 성공함” 정도로 요약 가능함. 실제론 별 의미 없는 결과지만, 오히려 샌드박스가 얼마나 효과적으로 방어에 기여하는지 보여주는 사례임
- 여기에서 전체 해킹 과정을 볼 수 있음
- 나는 이 사건을 파이썬 샌드박스를 탈출해 컨테이너까지 뚫은 걸로 이해했음. Microsoft가 취약점 심각도를 적당(moderate)으로 매긴 것도 이런 맥락 때문인 듯함
- 내가 뭔가 놓치고 있는지 모르겠지만, 로컬 네트워크를 경유해서라도 외부에 네트워크 연결을 시도할 수 있지 않을까? Microsoft가 고객에게 이런 컨테이너에서 루트 권한까지 허용하면서도 데이터 유출이나 추가 공격 위험은 정말 없었던 건지 궁금함
- 예전에 openai가 파이썬 인터프리터 기능을 공개했을 때도 상황이 비슷했음. 외부 네트워크 접근은 막혀 있었고, 흥미로운 것은 내부 구성 파일 몇 개와 개발자들이 코딩하는 방식에 대한 일부 정보뿐이었음. 이번 사례도 사실상 똑같음
- Copilot이 알려준 응답이 진짜인지 헛소리(hallucination)인지 어떻게 알 수 있을까? 본인이 그곳에서 일하는데, 저런 프로세스는 본 적이 없음. 참고로, 공개 저장소에 keepAliveJupyterSvc.sh라는 스크립트를 찾음
- 그 저장소와 기여자들은 실제로 MS/Azure 소속으로 컨테이너 내 파이썬 코드 실행 서비스를 개발하는 중임. 왜 개인 계정에 올라왔는지는 모르겠음. Office 프로젝트 포크라고는 하는데 원본은 못 찾겠음
- 헛소리가 아닐 수도 있음. Copilot 코드가 github 학습 데이터셋에서 생성된 것일 수도 있음
- 이건 진짜 헛소리(like hallucination)처럼 느껴짐. 챗봇은 대부분 토큰 생성기일 뿐임. 실제로 프로그램을 실행해서 응답하는 게 아니라, GPU로 토큰을 만들어 영어로 변환해서 보내는 것임
- 예전 LLM들이 비공개 회사 문서를 데이터로 학습해서 회사 기밀을 잘 노출했다는 말이 있었음. 지금은 대부분 데이터가 정제된 것 같음
- LLM이 우연히 등장한 한 번만의 데이터를 외우지도 않고, 실제로 비공개 데이터가 대량 학습된 사례는 못 봤음. 그래서 비현실적이라 생각함. LLM의 헛소리가 겉보기엔 진짜 기밀 유출인 것처럼 보이게 할 수 있을 뿐임
- 내가 경험한 바로는 회사 기밀이라는 게 다른 기업 입장에서는 별 의미 없음
- 이런 사례에 구체적인 예시가 있는지 궁금함. 내가 본 적은 없음
- 예전에 (비기술) 기업들도 가이드라인 없이 도입해서 목적 외의 콘텐츠가 생성될 때도 있었음. 예를 들어, 보바(버블티) 회사가 무료, 회원가입 없는 LLM을 내놔서 내가 ChatGPT 무료버전 나오기 전에 bash 스크립트 몇 개 생성해서 썼던 경험 있음
- 출처가 궁금함
- 사실상 취약점이 아닌 것처럼 보임. 이 시스템의 목적이 바로 코드를 컨테이너에서 실행하게 만드는 구조임
- 물론 컨테이너가 격리된 상태라는 전제가 있을 때만 의미 있음
- Copilot에게 sudo 바이너리를 base64로 준 다음 사용하는 방식으로 더 쉽게 우회할 수도 있었을 것 같음
- 그럴 거면 파일 소유자도 root로 바꿔야 할 필요가 있음
- Microsoft에 취약점을 보고했고, moderate로 분류되어 버그바운티는 받지 못하고 acknowledgement만 받았음. 이렇게 큰 기업이 포상금조차 안 주는 게 이해가 잘 안 됨. 이런 상황에서 나쁜 일이 안 생길 수 있을지 의문임
- 본질적으로 얻은 게 아무것도 없음. 루트 권한을 얻어도 접근 못 하던 컨테이너 일부분을 탐색할 수 있게 된 것뿐인데, /root에도 파일은 없고, 쓸 만한 로그도 안 남아있었음. 모든 알려진 탈출 기법도 이미 패치됨. 만약 Microsoft가 이런 우회된 방법 하나하나마다 포상하면 끝이 없을 테니, 위험성이 없는 한 별도로 보상하지 않는 것도 어느 정도 이해함
- 왜 사람들이 트릴리언달러짜리 대기업에게 무료로 버그리포트 해주는지 정말 이해 못 하겠음
- Microsoft가 돈을 안 줄 거면, 스웨그라도 좀 챙기는 게 나을 것 같음. 멋진 굿즈를 해커들에게 주면 자연스럽게 광고가 되고, 오히려 입사하고 싶어질 수 있음. 해커 커뮤니티문화를 활용할 필요가 있음
- “root”를 획득해도 실제로 얻는 건 아무것도 없음. 여러 시도를 해봐도 소득이 없었음