Lỗ hổng thực thi mã tùy ý phá vỡ sandbox trong KDE Plasma

• PoC xác nhận rằng do hành vi quản lý cửa sổ của KDE Plasma, một ứng dụng bị sandbox có thể thực thi binary tùy ý trên host khi người dùng nhấp chuột
• Nguyên nhân cốt lõi là KWin tin tưởng app_id do ứng dụng cung cấp và vẫn giữ đường dẫn thực thi dựa trên /proc/PID/cmdline mà không đối chiếu với tệp .desktop thực tế
• PoC kết hợp host Arch Linux, ứng dụng Flatpak và Mesa eglgears_wayland đã chỉnh sửa để tái hiện luồng trong đó /usr/bin/kcalc được chạy bên ngoài sandbox
• Khi người dùng chọn Open New Window trên biểu tượng ở thanh tác vụ hoặc nhấp chuột giữa, tiến trình mục tiêu được khởi chạy trong trạng thái lộ diện ở cgroup app.slice và mount namespace của host
• Để giảm thiểu, cần xác minh app ID từ security context của sandbox, XdpAppInfo, control groups, và chặn việc khởi chạy cửa sổ mới đối với các cửa sổ không khớp với tệp .desktop

---

Luồng thoát sandbox mà PoC cho thấy

• Ứng dụng sandbox độc hại có thể giả mạo một ứng dụng khác và thực thi binary tùy ý trên host ngay lúc người dùng gọi Open New Window
• PoC được tái hiện bằng Flatpak, nhưng bài viết tổng kết rằng vấn đề cũng có thể áp dụng cho các sandbox khác, bất kể có hỗ trợ security context hay không
• Cấu hình thử nghiệm như sau
  • Host Arch Linux
  • Phụ thuộc build wget, unzip, meson
  • Ứng dụng Flatpak không được cấp quyền io.github.johannesboehler2.BmiCalculator
  • Do khó build trong sandbox, chỉ truyền đường dẫn binary độc hại vào Flatpak
  • Binary mục tiêu được chỉ định /usr/bin/kcalc
• Khi chạy binary độc hại, biểu tượng KCalc sẽ hiển thị trên thanh tác vụ
• Khi người dùng nhấp chuột phải rồi chọn Open New Window, /usr/bin/kcalc được khởi động bên ngoài sandbox
  • Vị trí thực thi là cgroup app.slice
  • Mount namespace thuộc phía host
  • Kết quả là nó chạy trong trạng thái hoàn toàn lộ diện

Quá trình phát hiện và các manh mối

• Trong khi kiểm thử sandbox Portable bằng máy ảo QEMU trên KDE Plasma, một số cửa sổ không được liên kết với tệp .desktop phù hợp nên hiển thị trên thanh tác vụ bằng biểu tượng Wayland chung
• Hiện tượng này đã được báo cáo trong KWin trusts on Apps fully for app_id, dẫn đến vấn đề ứng dụng có thể giả mạo ứng dụng khác
• Sau đó, khi vô tình nhấp chuột giữa trên thanh tác vụ, hành vi mặc định Open New Window được gọi
• Cửa sổ mới đã được chạy, nhưng không sử dụng thông tin đăng nhập đã lưu và cấu hình đã chỉnh sửa; khi kiểm tra cùng lúc PID trong KWin Debug Console và thông tin control groups cùng rootfs trong procfs, việc thoát sandbox đã lộ ra

Cách lỗ hổng hoạt động

• Ngay cả khi KWin không thể liên kết cửa sổ với tệp .desktop thực tế, vẫn còn một đường dẫn để tìm argv0 sẽ được thực thi
• Kết quả thử nghiệm cho thấy phỏng đoán rằng giá trị được đọc qua /proc/PID/cmdline là đúng
• Vấn đề không chỉ dừng ở mức chạy một instance ứng dụng hiện có bên ngoài sandbox
• Mọi tiến trình, bao gồm cả tiến trình không có đặc quyền, đều có thể thay đổi argv0
  • Mount namespace cũng có thể là một lựa chọn, nhưng được tổng kết là kém linh hoạt hơn
• Việc thiếu bảo vệ đối với app_id do ứng dụng cung cấp kết hợp với tính không an toàn của việc đọc /proc/PID/cmdline khiến thực thi mã tùy ý trên host trở nên khả thi

Demo và kịch bản tấn công thực tế

• Mã demo do GalaxySnail viết, sử dụng eglgears-wayland của Mesa
• Luồng demo như sau
  • Clone repository mesa-demos-argv0
  • Sửa lệnh được chỉ định trong hàm main của src/egl/opengl/eglgears.c thành lệnh mong muốn
  • Build bằng meson setup build && meson compile -C build
  • Chạy ./build/src/egl/opengl/eglgears_wayland
  • Nhấp chuột giữa vào biểu tượng trên thanh tác vụ hoặc chọn Open New Window trong menu ngữ cảnh
  • Binary độc hại đã chỉ định được khởi động
• Trong tấn công thực tế, có thể tạo shell script dưới $HOME
  • $HOME thường cũng nằm ở cùng đường dẫn trên host
  • Ứng dụng độc hại có thể âm thầm tạo argv0 hoặc thay bằng binary đã tải xuống
  • Nếu người dùng nhấp Open New Window hoặc vô tình nhấp chuột giữa vào biểu tượng ứng dụng, kẻ tấn công có thể kiểm soát hoàn toàn phiên làm việc

Hướng sửa được đề xuất

• Để KDE Plasma ngăn chặn exploit này, không nên tin tưởng nguyên trạng ID do ứng dụng cung cấp
• Bài viết đề xuất lấy app ID từ các đường dẫn sau
  • security context của sandbox
  • XdpAppInfo
  • control groups
• Nếu một cửa sổ cụ thể không khớp với tệp .desktop, không nên cho phép Open New Window
• Hiện chưa nhận được cập nhật từ email KDE Security

Dòng thời gian công khai

• Trong email ban đầu, arbitrary code execution đã bị ghi nhầm là RCE
• Tất cả sự kiện dựa trên UTC+8, định dạng 24 giờ
• 23:51 ngày 1 tháng 4 năm 2026, gửi email đầu tiên đến [e-mail]
• 00:15 ngày 2 tháng 4 năm 2026, David Edmundson phản hồi xác nhận báo cáo
• 00:24 ngày 2 tháng 4 năm 2026, David Edmundson trả lời rằng tính năng này dùng Exec= trong tệp .desktop và ông cho rằng không thể dùng để thực thi mã tùy ý
• 11:59 ngày 2 tháng 4 năm 2026, với sự giúp đỡ của GalaxySnail, xác nhận một PoC khác không phụ thuộc vào tệp .desktop hoạt động
• 18:26 ngày 2 tháng 4 năm 2026, gửi email tiếp theo kèm tệp exploit và mô tả đến [e-mail], nhưng không nhận được phản hồi
• 11:59 ngày 2 tháng 5 năm 2026, xác nhận exploit chưa được vá trong Plasma 6.7 Beta
• 18:30 ngày 2 tháng 7 năm 2026, exploit vẫn hoạt động và đã vượt quá thời gian chờ 90 ngày nên tiến hành công khai
• Vì lỗ hổng chưa được vá, không nhận được phản hồi tiếp theo và thời gian chờ thông thường 90 ngày đã trôi qua, tác giả quyết định công khai để nâng cao nhận thức
• Tác giả nói thêm rằng đây không phải là nỗ lực chỉ trích các nhà phát triển KDE; các dự án OSS gần đây phải chịu nhiều spam và con người cũng có giới hạn về năng lực xử lý, nhưng quy trình có thể được cải thiện hơn

[GN⁺]

Các ý kiến trên Lobste.rs

• Thật sự ước gì nỗ lực đưa Capsicum lên Linux đã không chết vì NIH
  Với sandboxing ứng dụng desktop, đó là một mô hình tốt hơn nhiều so với mớ cách tiếp cận lộn xộn đang được chồng chất trên Linux để cố làm điều tương tự. Launcher truyền tập quyền ban đầu, tức các file descriptor, dựa trên metadata; ứng dụng không thể truy cập gì ngoài chúng, còn powerbox cung cấp quyền mở/lưu các tệp khác
  • Toàn bộ mô hình container của Linux trông giống như một sự chắp vá của các khái niệm khá vụng về
    Nó nhìn chung phù hợp với môi trường nơi một tiến trình kiểu “thần thánh” điều phối dịch vụ, như dịch vụ Kubernetes, nhưng không hợp lắm trên desktop. Người dùng muốn đi vào một cgroup/namespace có quyền thấp hơn từ user space, nhưng lại phải đi qua các nghi thức như root daemon hoặc setuid, rốt cuộc kéo theo rủi ro leo thang đặc quyền
  • Về lý thuyết, các công cụ sandbox desktop Linux chủ đạo như Flatpak nên vận hành theo cách này, lấy SCM_RIGHTS + Wayland + D-Bus làm các thành phần nền tảng
    Nếu nheo mắt nhìn thì cũng thấy được phác thảo của một desktop an toàn
    Nhưng triển khai thực tế nhìn chung hoặc quá rộng rãi, hoặc thiếu linh hoạt, hoặc hỏng dở dang. Dường như không có mấy ai quan tâm đến bảo mật desktop đầu-cuối nhiều như việc chăm lo bảo mật workload máy chủ. Vì vậy gVisor và Firecracker hoạt động tốt, còn Flatpak thì khó chạy nổi một ứng dụng Gtk+ cơ bản mà không làm hỏng phông chữ, và mọi Wayland compositor đều phải tự triển khai lại một nửa nền tảng desktop đáng tin cậy
    Càng đáng xấu hổ hơn khi nghĩ rằng Android đã làm khá tốt vai trò một bản phân phối Linux được gia cố đủ để chạy mã không đáng tin cậy, còn iOS và macOS đã cho thấy sandboxing ứng dụng hướng người dùng cũng có thể đủ dễ dùng. Chỉ cần làm theo cách họ làm là được. Rốt cuộc tại sao lại có thứ gì đó bên trong trình quản lý cửa sổ đang đọc /proc/{pid}/cmdline?
• Tình huống này trông không hay, vì sau khi upstream không vá được thì đã dẫn đến công khai toàn bộ
  Nói vậy hoàn toàn không phải là chỉ trích nhà nghiên cứu
• Không rõ báo cáo issue gửi upstream có cũng theo kiểu này không, nhưng khá khó theo dõi
  Có lẽ nếu quen thuộc hơn với cấu trúc nội bộ của KDE hoặc Flatpak thì sẽ hiểu tốt hơn nhiều