Cách chúng tôi root Copilot

• Vào tháng 4/2025, Copilot Enterprise được cập nhật thêm sandbox Python thời gian thực (dựa trên Jupyter Notebook), cho phép thực thi mã backend
• Thông qua cú pháp %command của Jupyter Notebook, việc thực thi mã tùy ý trên hệ thống nền khá dễ dàng, và các lệnh Linux cũng có thể chạy dưới người dùng ubuntu (môi trường miniconda)
• Có một lỗ hổng bảo mật khi đường dẫn /app/miniconda/bin cho phép người dùng ubuntu ghi và còn được ưu tiên trong $PATH của root, nên có thể ghi đè các lệnh quan trọng như pgrep
• Bằng cách khai thác điều này, nhóm nghiên cứu đã giành được quyền root, nhưng bên trong container được cô lập rất chặt nên không thể thoát container, cũng không có rò rỉ thêm thông tin nào
• Lỗ hổng này được báo cáo vào tháng 4 và đến tháng 7 thì được vá với mức rủi ro trung bình, không có tiền thưởng mà chỉ được ghi tên trong danh sách researcher

---

Phân tích lỗ hổng của Microsoft Copilot Enterprise Jupyter Sandbox

Tổng quan về môi trường Jupyter của Copilot Enterprise

• Từ tháng 4/2025, Copilot Enterprise đã triển khai sandbox Python dựa trên Jupyter Notebook
• Người dùng có thể thực thi lệnh hệ thống Linux thông qua cú pháp %command của Jupyter
• Môi trường chạy với quyền người dùng ubuntu trên nền miniconda, không có binary sudo
• Có thể khám phá nhiều thành phần như biến môi trường, mạng, hệ thống tệp, thông tin tiến trình, v.v.

Cách vận hành và cấu trúc bên trong container

• Copilot tương tự sandbox của ChatGPT nhưng dùng kernel mới hơn và Python 3.12
• Các tiến trình chính: Jupyter Notebook, goclientapp viết bằng Go (chạy trên cổng 6000), httpproxy v.v.
• Mạng chỉ bật loopback và một số giao diện link-local bị hạn chế
• Hệ thống tệp dùng OverlayFS dựa trên đường dẫn /legion, với các script tùy biến nằm trong /app

Tải xuống và thao tác tệp

• Có thể tải xuống bình thường các tệp văn bản / đầu ra lệnh, nhưng tệp nhị phân có nguy cơ bị hỏng, nên cần mã hóa base64
• Tệp nằm trong /mnt/data và tạo liên kết tải xuống bên ngoài dưới dạng blob URL

Cấu trúc goclientapp/httpproxy

• goclientapp: nhận mã từ bên ngoài qua endpoint /execute (định dạng JSON), thực thi trong môi trường Jupyter rồi trả kết quả
• httpproxy: proxy lưu lượng HTTP đi ra ngoài từ Jupyter (đang bị vô hiệu hóa với ENABLE_EGRESS=false)

Lỗ hổng trong script entrypoint.sh

• Trong entrypoint.sh, là script entrypoint của container, nhiều dịch vụ (goclientapp, httpproxyapp) chạy với quyền người dùng ubuntu
• Chỉ có keepAliveJupyterSvc.sh tiếp tục chạy với quyền root
• Ở dòng 28 có lệnh pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888", hoạt động theo thứ tự ưu tiên thư mục trong $PATH
• /app/miniconda/bin đứng trước /usr/bin trong PATH của cả root lẫn người dùng ubuntu → có thể thay thế tùy ý các lệnh như pgrep

Quá trình giành quyền root và các giới hạn

• Kẻ tấn công tạo một script pgrep độc hại trong /app/miniconda/bin, khiến entrypoint.sh định kỳ thực thi tệp này với quyền root
• Script đó đọc tệp /mnt/data/in, thực thi nội dung như lệnh shell, rồi lưu kết quả vào /mnt/data/out
• Bằng cách này, họ đã giành được quyền root bên trong container, nhưng vẫn không thể truy cập thông tin nhạy cảm như tệp trong /root, log, v.v., cũng như không thể thoát container
• Container đã được vá để chặn mọi kịch bản breakout khác nhau

Phản hồi của Microsoft và kết quả

• 18/4/2025: Eye Security gửi báo cáo lỗ hổng cho MSRC
• 25/7/2025: Microsoft phân loại là mức độ nghiêm trọng trung bình (moderate severity), vá xong thì đóng issue và ghi tên nhà nghiên cứu vào danh sách (không trả bug bounty)

Tham khảo và phụ lục

• Eye Security là một công ty an ninh mạng có trụ sở tại châu Âu, cung cấp giám sát mối đe dọa 24/7, ứng phó sự cố, bảo hiểm mạng, v.v.

• Các trường hợp xâm nhập dịch vụ Microsoft nội bộ (Entra OAuth, v.v.) bao gồm cả lỗ hổng này dự kiến sẽ được trình bày tại BlackHat USA 2025

• Dòng thời gian

  • 18/4/2025 – Báo cáo lên MSRC
  • 25/7/2025 – Vá lỗi và đóng case, đăng bài blog

[GN⁺]

Ý kiến trên Hacker News

• Điểm cốt lõi của lỗ hổng này là hiểu rằng, trong thiết kế ban đầu chỉ định cấp quyền người dùng thường bên trong container, nhưng bằng một mẹo nào đó vẫn có thể thực thi mã với quyền root. Tuy nhiên trên thực tế, bản thân container đã được cô lập rất kỹ nên không thể truy cập mạng hay thoát ra ngoài, vì vậy những gì có thể làm với quyền root cũng chỉ là tự phá hỏng container của chính mình
  • Phải công nhận Microsoft đã cấu hình bảo mật cực kỳ chặt chẽ. Đa số công ty không cô lập hoàn hảo đến mức này
  • Không rõ chính xác container này được triển khai như thế nào. Microsoft đang dùng cách tiêu chuẩn để cô lập Python sandbox (Azure container-apps session), nên hy vọng tính năng này cũng dùng cách đó hoặc một phương thức tương tự
  • Việc Copilot lúc thì từ chối thực thi mã, lúc thì lại cho phép, tạo cảm giác hơi kỳ lạ. Không rõ chính xác họ đang nhắm đến phạm vi nào
  • Ngày nay lỗ hổng thường xếp chồng thành cả một stack, nên câu nói “container là an toàn” thực chất chỉ có nghĩa là kẻ tấn công chưa tìm ra lỗ hổng mà thôi. Container escape hay VM escape đều đã là các kiểu tấn công được biết đến, và chỉ cần một lỗi nhỏ như cấu hình sai hoặc bug trong driver virtio cũng có thể bị xuyên thủng. Trường hợp này thực sự là một kết quả đáng chú ý
• Nhìn tiêu đề kiểu “How We Rooted Copilot” tôi tưởng là họ đã đột phá được VM lõi của Copilot thật, nhưng thực tế chỉ là giành được quyền root trong một container Python sandbox bị giới hạn cực mạnh. Tiêu đề chính xác hơn phải là “How We Rooted the Copilot Python Sandbox”
  • Có thể tóm tắt là “đã leo thang đặc quyền từ người dùng thường lên root trong một sandbox bị cô lập hoàn toàn”. Về thực tế thì gần như không có nhiều ý nghĩa, nhưng ngược lại đây lại là ví dụ cho thấy sandbox đóng góp hiệu quả thế nào vào phòng thủ
• Có thể xem toàn bộ quá trình hack tại đây
• Tôi đã hiểu sự việc này là thoát khỏi Python sandbox rồi đột phá luôn cả container. Có lẽ đó cũng là bối cảnh khiến Microsoft xếp mức độ nghiêm trọng của lỗ hổng này là moderate
• Không biết tôi có đang bỏ sót gì không, nhưng liệu có thể thử kết nối ra ngoài mạng, dù chỉ qua local network, hay không? Tôi thắc mắc liệu Microsoft có thực sự chắc chắn là việc cho phép quyền root trong loại container này không tạo ra nguy cơ rò rỉ dữ liệu hay các đợt tấn công tiếp theo
  • Trước đây khi OpenAI công bố tính năng Python interpreter thì tình hình cũng tương tự. Truy cập mạng bên ngoài bị chặn, và những thứ thú vị duy nhất chỉ là vài file cấu hình nội bộ cùng một ít thông tin về cách các lập trình viên viết code. Trường hợp này về cơ bản cũng y hệt như vậy
• Làm sao biết được phản hồi Copilot đưa ra là thật hay chỉ là bịa đặt (hallucination)? Tôi làm việc ở đó mà chưa từng thấy quy trình như thế. Nhân tiện, tôi tìm thấy một script tên là keepAliveJupyterSvc.sh trong một kho công khai
  • Kho đó và những người đóng góp cho nó thực sự thuộc MS/Azure và đang phát triển dịch vụ thực thi mã Python trong container. Không rõ vì sao nó lại nằm trên tài khoản cá nhân. Họ có nói đó là một fork của dự án Office, nhưng tôi không tìm ra bản gốc
  • Có thể không phải bịa đặt. Mã Copilot có thể đã được sinh ra từ bộ dữ liệu huấn luyện của GitHub
  • Cái này đúng là có cảm giác giống bịa đặt thật. Phần lớn chatbot chỉ là cỗ máy sinh token. Nó không thực sự chạy chương trình để tạo phản hồi, mà chỉ tạo token bằng GPU rồi chuyển thành tiếng Anh để gửi đi
• Trước đây từng có chuyện nói rằng các LLM đời cũ học từ tài liệu nội bộ không công khai của công ty nên để lộ bí mật doanh nghiệp khá nhiều. Có vẻ bây giờ phần lớn dữ liệu đã được làm sạch
  • Tôi chưa thấy trường hợp nào LLM ghi nhớ một dữ liệu chỉ xuất hiện ngẫu nhiên đúng một lần, cũng chưa thấy ví dụ nào về việc lượng lớn dữ liệu riêng tư thực sự bị dùng để huấn luyện. Vì thế tôi thấy điều đó không thực tế. Chỉ là sự bịa đặt của LLM có thể trông giống như rò rỉ bí mật thật mà thôi
  • Theo kinh nghiệm của tôi thì cái gọi là bí mật công ty thường cũng chẳng có nhiều ý nghĩa với doanh nghiệp khác
  • Tôi tò mò không biết có ví dụ cụ thể nào cho những trường hợp như vậy không. Tôi chưa từng thấy
  • Trước đây ngay cả các công ty (phi kỹ thuật) cũng từng triển khai mà không có hướng dẫn, nên đôi khi mô hình tạo ra nội dung ngoài mục đích sử dụng. Ví dụ, có một công ty boba đã tung ra một LLM miễn phí, không cần đăng ký, và tôi từng dùng nó để tạo vài script bash trước khi bản miễn phí của ChatGPT ra mắt
  • Tôi muốn biết nguồn của chuyện đó
• Trên thực tế chuyện này trông gần như không phải là lỗ hổng. Mục tiêu của hệ thống này vốn chính là cho phép chạy code trong container
  • Tất nhiên điều đó chỉ có ý nghĩa khi giả định container đang ở trạng thái cô lập
• Có vẻ còn có thể vượt qua dễ hơn bằng cách đưa cho Copilot binary sudo ở dạng base64 rồi dùng nó
  • Nếu vậy thì còn phải đổi chủ sở hữu file sang root nữa
• Đã báo lỗ hổng cho Microsoft, nhưng họ xếp loại moderate nên không được bug bounty mà chỉ được acknowledgement. Tôi thực sự không hiểu nổi tại sao một công ty lớn như vậy lại không trả nổi cả tiền thưởng. Khó mà tin là sẽ không có chuyện xấu xảy ra trong những tình huống như thế này
  • Về bản chất thì chẳng đạt được gì cả. Dù có quyền root thì cũng chỉ khám phá thêm được một phần container vốn trước đó không truy cập được; trong /root cũng không có file gì, và cũng không còn log hữu ích nào. Mọi kỹ thuật escape đã biết đều đã được vá. Nếu Microsoft phải thưởng cho từng cách lách luật kiểu này thì sẽ không có điểm dừng, nên ở mức không có rủi ro thực tế thì việc họ không trả thưởng riêng cũng phần nào dễ hiểu
  • Tôi thật sự không hiểu vì sao mọi người lại gửi bug report miễn phí cho các tập đoàn lớn trị giá hàng nghìn tỷ đô
  • Nếu Microsoft không muốn trả tiền, thì ít nhất phát ít swag còn hay hơn. Tặng đồ lưu niệm đẹp cho hacker vừa thành quảng cáo tự nhiên, vừa có thể khiến người ta muốn vào làm việc hơn. Nên tận dụng văn hóa cộng đồng hacker
  • Dù có giành được “root” thì thực tế cũng chẳng thu được gì. Thử đủ cách vẫn không có kết quả gì