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

> Clean Markdown view of GeekNews topic #31103. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31103](https://news.hada.io/topic?id=31103)
- GeekNews Markdown: [https://news.hada.io/topic/31103.md](https://news.hada.io/topic/31103.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-04T09:25:48+09:00
- Updated: 2026-07-04T09:25:48+09:00
- Original source: [blog.kimiblock.top](https://blog.kimiblock.top/2026/07/01/arbitrary-code-execution-in-kde-plasma/)
- Points: 1
- Comments: 1

## Topic Body

- 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](https://bugs.kde.org/show_bug.cgi?id=502309)로 보고됐으며, 앱이 다른 앱으로 가장할 수 있는 문제로 이어짐
- 이후 작업 표시줄에서 실수로 중간 클릭을 하자 기본 동작으로 **Open New Window**가 호출됨
- 새 창은 실행됐지만 저장된 로그인 자격 증명과 수정된 설정을 사용하지 않았고, KWin Debug Console의 PID와 procfs의 control groups 및 rootfs 정보를 함께 확인하면서 샌드박스 탈출이 드러남

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

### 데모와 실제 공격 시나리오
- 데모 코드는 [GalaxySnail](https://github.com/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](https://github.com/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 프로젝트가 최근 스팸에 시달리고 인간에게도 처리 용량의 한계가 있지만 프로세스는 더 나아질 수 있다고 덧붙임

## Comments



### Comment 61244

- Author: neo
- Created: 2026-07-04T09:25:49+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/ovcwkm/arbitrary_code_execution_breaking) 
- 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 내부 구조에 더 익숙하면 훨씬 잘 이해됐을 것 같음