KDE Plasma에서 샌드박스를 깨는 임의 코드 실행 취약점

 (blog.kimiblock.top)
1P by GN⁺ | ★ favorite | 댓글 1개
  • KDE Plasma의 창 관리 동작 때문에 샌드박스된 앱이 사용자의 클릭을 계기로 호스트 임의 바이너리를 실행할 수 있음이 PoC로 확인됨
  • 핵심 원인은 KWin이 앱이 제공한 app_id를 신뢰하고, 실제 .desktop 파일 매칭 없이 /proc/PID/cmdline 기반 실행 경로를 남겨둔 데 있음
  • PoC는 Arch Linux 호스트와 Flatpak 앱, 수정된 Mesa eglgears_wayland를 조합해 /usr/bin/kcalc가 샌드박스 밖에서 실행되는 흐름을 재현함
  • 사용자가 작업 표시줄 아이콘의 Open New Window를 선택하거나 중간 클릭하면 대상 프로세스가 app.slice cgroup과 호스트 마운트 네임스페이스에서 노출된 상태로 시작됨
  • 완화하려면 샌드박스의 security context, XdpAppInfo, control groups에서 앱 ID를 확인하고, .desktop 파일과 맞지 않는 창에는 새 창 실행을 막아야 함

PoC가 보여준 샌드박스 탈출 흐름

  • 악성 샌드박스 앱은 사용자가 Open New Window를 호출하는 순간 다른 앱으로 가장해 호스트에서 임의 바이너리를 실행할 수 있음
  • PoC는 Flatpak으로 재현됐지만, 보안 컨텍스트 지원 여부와 관계없이 다른 샌드박스에도 적용될 수 있다고 정리함
  • 실험 구성은 다음과 같음
    • Arch Linux 호스트
    • 빌드 의존성 wget, unzip, meson
    • 권한을 부여하지 않은 Flatpak 앱 io.github.johannesboehler2.BmiCalculator
    • 샌드박스 안에서 빌드가 쉽지 않아 악성 바이너리 경로만 Flatpak에 전달
    • 지정 대상 바이너리 /usr/bin/kcalc
  • 악성 바이너리를 실행하면 작업 표시줄에는 KCalc 아이콘이 표시됨
  • 사용자가 우클릭 후 Open New Window를 선택하면 /usr/bin/kcalc가 샌드박스 밖에서 시작됨
    • 실행 위치는 app.slice cgroup
    • 마운트 네임스페이스는 호스트 쪽
    • 결과적으로 완전히 노출된 상태로 실행됨

발견 과정과 단서

  • KDE Plasma에서 Portable 샌드박스를 QEMU 가상 머신으로 테스트하던 중, 일부 창이 적절한 .desktop 파일과 연결되지 않아 작업 표시줄에 일반 Wayland 아이콘으로 표시됨
  • 이 현상은 KWin trusts on Apps fully for app_id로 보고됐으며, 앱이 다른 앱으로 가장할 수 있는 문제로 이어짐
  • 이후 작업 표시줄에서 실수로 중간 클릭을 하자 기본 동작으로 Open New Window가 호출됨
  • 새 창은 실행됐지만 저장된 로그인 자격 증명과 수정된 설정을 사용하지 않았고, KWin Debug Console의 PID와 procfs의 control groups 및 rootfs 정보를 함께 확인하면서 샌드박스 탈출이 드러남

취약점의 작동 방식

  • KWin이 창을 실제 .desktop 파일에 연결하지 못하더라도, 실행할 argv0를 찾는 경로가 남아 있음
  • 실험 결과 /proc/PID/cmdline을 통해 값을 읽는다는 추측이 맞았음
  • 문제는 기존 애플리케이션 인스턴스를 샌드박스 밖에서 실행하는 수준에 그치지 않음
  • 권한 없는 프로세스를 포함한 모든 프로세스는 argv0를 바꿀 수 있음
    • 마운트 네임스페이스도 선택지가 될 수 있지만 덜 유연하다고 정리함
  • 앱 제공 app_id에 대한 보호 부재와 /proc/PID/cmdline 읽기의 불안전성이 결합해 호스트에서 임의 코드 실행이 가능해짐

데모와 실제 공격 시나리오

  • 데모 코드는 GalaxySnail이 작성했으며, Mesa의 eglgears-wayland를 사용함
  • 데모 흐름은 다음과 같음
    • mesa-demos-argv0 저장소를 클론
    • src/egl/opengl/eglgears.c의 main 함수 안 지정 명령을 원하는 명령으로 수정
    • meson setup build && meson compile -C build로 빌드
    • ./build/src/egl/opengl/eglgears_wayland 실행
    • 작업 표시줄 아이콘 중간 클릭 또는 컨텍스트 메뉴에서 Open New Window 선택
    • 지정한 악성 바이너리가 시작됨
  • 실제 공격에서는 $HOME 아래에 셸 스크립트를 생성하는 방식이 가능함
    • $HOME은 일반적으로 호스트에서도 같은 경로에 있음
    • 악성 앱은 argv0를 조용히 생성하거나 다운로드한 바이너리로 바꿀 수 있음
    • 사용자가 Open New Window를 클릭하거나 실수로 앱 아이콘을 중간 클릭하면 세션을 완전히 제어할 수 있음

제안된 수정 방향

  • KDE Plasma가 이 익스플로잇을 막으려면 앱이 제공한 ID를 그대로 신뢰하지 않아야 함
  • 앱 ID는 다음 경로에서 얻어야 한다고 제안함
    • 샌드박스의 security context
    • XdpAppInfo
    • control groups
  • 특정 창이 .desktop 파일과 매칭되지 않으면 Open New Window를 허용하지 않아야 함
  • KDE Security 메일로부터 업데이트를 받지 못한 상태임

공개 타임라인

  • 원래 메일에서 arbitrary code execution을 RCE로 잘못 표기함
  • 모든 이벤트는 UTC+8, 24시간 형식 기준임
  • 2026년 4월 1일 23:51, 첫 메일을 security@kde.org로 보냄
  • 2026년 4월 2일 00:15, David Edmundson이 보고를 확인하는 답장을 보냄
  • 2026년 4월 2일 00:24, David Edmundson은 해당 기능이 .desktop 파일의 Exec=를 사용하며 임의 코드 실행에 쓰일 수 없다고 생각한다고 답함
  • 2026년 4월 2일 11:59, GalaxySnail의 도움으로 .desktop 파일에 의존하지 않는 다른 PoC가 동작함을 확인함
  • 2026년 4월 2일 18:26, 익스플로잇 파일과 설명을 포함한 후속 메일을 security@kde.org로 보냈지만 응답을 받지 못함
  • 2026년 5월 2일 11:59, Plasma 6.7 Beta에서 익스플로잇이 패치되지 않았음을 확인함
  • 2026년 7월 2일 18:30, 익스플로잇이 활성 상태로 90일 대기 기간을 넘겨 공개를 진행함
  • 패치되지 않았고 후속 답장을 받지 못했으며 일반적인 90일 대기 기간이 지난 뒤, 인식 제고를 위해 공개를 결정함
  • KDE 개발자를 비판하려는 시도는 아니며, OSS 프로젝트가 최근 스팸에 시달리고 인간에게도 처리 용량의 한계가 있지만 프로세스는 더 나아질 수 있다고 덧붙임

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들
  • Linux용 Capsicum 시도가 NIH 때문에 죽지 않았으면 정말 좋았을 텐데 싶음
    데스크톱 앱 샌드박싱에는 지금 Linux에서 같은 걸 해보려고 쌓아 올린 잡다한 방식들보다 훨씬 나은 모델임. 런처가 메타데이터를 바탕으로 초기 권한 집합, 즉 파일 디스크립터를 넘겨주고 앱은 그 외에는 접근하지 못하며, powerbox가 다른 파일 열기·저장 권한을 제공하는 구조임
    • Linux의 컨테이너 모델 전체가 좀 엉성한 개념들의 짜깁기처럼 보임
      Kubernetes 서비스처럼 어떤 신적 프로세스가 서비스를 오케스트레이션하는 환경에는 대체로 맞지만, 데스크톱에서는 잘 맞지 않음. 사용자 공간에서 더 낮은 권한의 cgroup/namespace로 들어가고 싶은데, root 데몬이나 setuid 같은 의식을 거쳐야 해서 결국 권한 상승 위험을 부름
    • 이론적으로는 Flatpak 같은 주요 Linux 데스크톱 샌드박스 도구들이 SCM_RIGHTS + Wayland + D-Bus를 기본 요소로 삼아 이렇게 동작해야 함
      눈을 가늘게 뜨고 보면 안전한 데스크톱의 윤곽이 보이긴 함
      하지만 실제 구현은 전반적으로 너무 관대하거나, 융통성이 없거나, 반쯤 망가져 있음. 서버 워크로드 보안을 챙기는 것만큼 종단 간 데스크톱 보안을 신경 쓰는 사람이 없어 보임. 그래서 gVisor와 Firecracker는 잘 동작하는데 Flatpak은 기본 Gtk+ 앱 하나도 글꼴을 깨지 않고 실행하기 어렵고, 모든 Wayland 컴포지터가 신뢰할 수 있는 데스크톱 기반의 절반을 다시 구현해야 함
      Android가 신뢰할 수 없는 코드를 실행할 만큼 충분히 강화된 Linux 배포판 역할을 꽤 잘 해냈고, iOS와 macOS는 사용자-facing 앱 샌드박싱도 충분히 쓰기 편할 수 있음을 보여줬다는 점을 생각하면 더 민망함. 그냥 그들이 하는 대로 하면 됨. 대체 왜 창 관리자 안의 무언가가 /proc/{pid}/cmdline 을 읽고 있는 건가
  • 업스트림이 패치하지 못한 뒤에 공개 공개로 이어진 상황이라 보기 좋지 않음
    이 말은 연구자를 향한 비판은 전혀 아님
  • 업스트림에 보낸 이슈 보고도 이런 식이었는지는 모르겠지만, 따라가기가 꽤 어려웠음
    KDE나 Flatpak 내부 구조에 더 익숙하면 훨씬 잘 이해됐을 것 같음
답변달기