ช่องโหว่รันโค้ดตามอำเภอใจที่เจาะแซนด์บ็อกซ์ได้ใน KDE Plasma

 (blog.kimiblock.top)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการยืนยันผ่าน PoC แล้วว่า เนื่องจากพฤติกรรมการจัดการหน้าต่างของ KDE Plasma แอปที่อยู่ในแซนด์บ็อกซ์สามารถรัน ไบนารีตามอำเภอใจบนโฮสต์ ได้เมื่อผู้ใช้คลิก
  • สาเหตุหลักคือ KWin เชื่อถือ app_id ที่แอประบุมา และยังคงมีเส้นทางการเรียกใช้งานที่อิง /proc/PID/cmdline โดยไม่มีการจับคู่กับไฟล์ .desktop จริง
  • PoC จำลองลำดับการทำงานที่ทำให้ /usr/bin/kcalc ถูกเรียกใช้นอกแซนด์บ็อกซ์ โดยใช้โฮสต์ Arch Linux, แอป Flatpak และ Mesa eglgears_wayland ที่ดัดแปลง
  • เมื่อผู้ใช้เลือก Open New Window จากไอคอนบนแถบงาน หรือคลิกปุ่มกลาง โปรเซสเป้าหมายจะเริ่มทำงานในสภาพที่เปิดเผยอยู่ใน app.slice cgroup และ host mount namespace
  • แนวทางบรรเทาคือควรตรวจสอบ app ID จาก security context ของแซนด์บ็อกซ์, XdpAppInfo และ control groups และต้องบล็อกการเปิดหน้าต่างใหม่สำหรับหน้าต่างที่ไม่ตรงกับไฟล์ .desktop

ลำดับการหลุดออกจากแซนด์บ็อกซ์ที่ PoC แสดงให้เห็น

  • แอปอันตรายภายในแซนด์บ็อกซ์สามารถปลอมตัวเป็นอีกแอปหนึ่งและรันไบนารีตามอำเภอใจบนโฮสต์ได้ทันทีที่ผู้ใช้เรียก Open New Window
  • แม้ PoC นี้จะสาธิตด้วย Flatpak แต่ผู้เขียนสรุปว่าสามารถใช้ได้กับแซนด์บ็อกซ์แบบอื่นเช่นกัน ไม่ว่าระบบนั้นจะรองรับ security context หรือไม่
  • ชุดทดสอบประกอบด้วยดังนี้
    • โฮสต์ Arch Linux
    • dependency สำหรับบิลด์ wget, unzip, meson
    • แอป Flatpak io.github.johannesboehler2.BmiCalculator ที่ไม่ได้ให้สิทธิ์เพิ่มเติม
    • เนื่องจากบิลด์ภายในแซนด์บ็อกซ์ได้ไม่ง่าย จึงส่งเข้า Flatpak เฉพาะพาธของไบนารีอันตราย
    • ไบนารีเป้าหมายที่ระบุคือ /usr/bin/kcalc
  • เมื่อรันไบนารีอันตราย แถบงานจะแสดง ไอคอน KCalc
  • เมื่อผู้ใช้คลิกขวาแล้วเลือก Open New Window /usr/bin/kcalc จะเริ่มทำงานนอกแซนด์บ็อกซ์
    • ตำแหน่งที่รันคือ app.slice cgroup
    • mount namespace เป็นฝั่งโฮสต์
    • ส่งผลให้รันในสภาพที่ถูกเปิดเผยอย่างสมบูรณ์

กระบวนการค้นพบและเบาะแส

  • ระหว่างทดสอบ Portable sandbox ของ KDE Plasma บน QEMU virtual machine ผู้วิจัยพบว่าบางหน้าต่างไม่ได้เชื่อมกับไฟล์ .desktop ที่เหมาะสม และจึงแสดงเป็น ไอคอน Wayland ทั่วไปบนแถบงาน
  • ปรากฏการณ์นี้ถูกรายงานไว้ที่ KWin trusts on Apps fully for app_id และนำไปสู่ปัญหาที่แอปสามารถปลอมตัวเป็นแอปอื่นได้
  • หลังจากนั้นผู้วิจัยเผลอคลิกปุ่มกลางบนแถบงาน ทำให้ Open New Window ถูกเรียกตามพฤติกรรมค่าเริ่มต้น
  • แม้หน้าต่างใหม่จะเปิดขึ้น แต่กลับไม่ใช้ข้อมูลล็อกอินที่บันทึกไว้หรือการตั้งค่าที่ปรับแต่งแล้ว และเมื่อเทียบ PID ใน KWin Debug Console กับข้อมูล control groups และ rootfs จาก procfs ก็พบการหลุดออกจากแซนด์บ็อกซ์

ช่องโหว่นี้ทำงานอย่างไร

  • แม้ KWin จะไม่สามารถเชื่อมหน้าต่างกับไฟล์ .desktop จริงได้ ก็ยังคงมีเส้นทางสำหรับค้นหา argv0 ที่จะใช้เรียกโปรแกรมอยู่
  • ผลการทดลองยืนยันว่าข้อสันนิษฐานที่ว่าอ่านค่าผ่าน /proc/PID/cmdline นั้นถูกต้อง
  • ปัญหานี้ไม่ได้จำกัดอยู่แค่การรันอินสแตนซ์เดิมของแอปพลิเคชันจากนอกแซนด์บ็อกซ์
  • ทุกโปรเซส รวมถึงโปรเซสที่ไม่มีสิทธิ์พิเศษ สามารถ เปลี่ยน argv0 ได้
    • แม้ mount namespace จะเป็นอีกทางเลือกหนึ่ง แต่ผู้เขียนสรุปว่ายืดหยุ่นน้อยกว่า
  • เมื่อไม่มีการปกป้อง app_id ที่แอประบุมากับการอ่าน /proc/PID/cmdline ที่ไม่ปลอดภัย จึงเปิดทางให้เกิดการรันโค้ดตามอำเภอใจบนโฮสต์ได้

เดโมและสถานการณ์โจมตีจริง

  • โค้ดเดโมเขียนโดย GalaxySnail และใช้ eglgears-wayland ของ Mesa
  • ขั้นตอนเดโมมีดังนี้
    • โคลนรีโพซิทอรี mesa-demos-argv0
    • แก้ไขคำสั่งที่ระบุไว้ในฟังก์ชัน main ของ src/egl/opengl/eglgears.c ให้เป็นคำสั่งที่ต้องการ
    • บิลด์ด้วย meson setup build && meson compile -C build
    • รัน ./build/src/egl/opengl/eglgears_wayland
    • คลิกปุ่มกลางที่ไอคอนบนแถบงาน หรือเลือก Open New Window จากเมนูบริบท
    • ไบนารีอันตรายที่กำหนดไว้จะเริ่มทำงาน
  • ในการโจมตีจริง สามารถใช้วิธีสร้าง shell script ไว้ใต้ $HOME
    • โดยทั่วไป $HOME มักเป็นพาธเดียวกันบนโฮสต์ด้วย
    • แอปอันตรายสามารถสร้าง argv0 อย่างเงียบ ๆ หรือแทนที่ด้วยไบนารีที่ดาวน์โหลดมา
    • หากผู้ใช้คลิก Open New Window หรือเผลอคลิกปุ่มกลางบนไอคอนแอป ผู้โจมตีก็สามารถควบคุมเซสชันได้ทั้งหมด

แนวทางแก้ไขที่เสนอ

  • หาก KDE Plasma ต้องการป้องกัน exploit นี้ ก็ไม่ควรเชื่อถือ ID ที่แอประบุมาตรง ๆ
  • มีข้อเสนอว่าควรดึง app ID จากเส้นทางต่อไปนี้
    • security context ของแซนด์บ็อกซ์
    • XdpAppInfo
    • control groups
  • หากหน้าต่างใดไม่สามารถจับคู่กับไฟล์ .desktop ได้ ก็ไม่ควรอนุญาต Open New Window
  • ผู้รายงานระบุว่ายังไม่ได้รับอัปเดตจากอีเมล KDE Security

ไทม์ไลน์การเปิดเผย

  • ในอีเมลฉบับแรกมีการระบุ arbitrary code execution เป็น RCE ผิดพลาด
  • ทุกเหตุการณ์ใช้เวลา UTC+8 และรูปแบบ 24 ชั่วโมง
  • 1 เมษายน 2026 23:51 ส่งอีเมลฉบับแรกไปที่ security@kde.org
  • 2 เมษายน 2026 00:15 David Edmundson ตอบกลับเพื่อยืนยันว่าได้รับรายงานแล้ว
  • 2 เมษายน 2026 00:24 David Edmundson ตอบว่าเขาเข้าใจว่าฟีเจอร์นี้ใช้ Exec= ในไฟล์ .desktop และจึงไม่น่าจะนำไปใช้รันโค้ดตามอำเภอใจได้
  • 2 เมษายน 2026 11:59 ยืนยันได้ด้วยความช่วยเหลือจาก GalaxySnail ว่า PoC อีกรูปแบบหนึ่งที่ไม่พึ่งพาไฟล์ .desktop ทำงานได้
  • 2 เมษายน 2026 18:26 ส่งอีเมลติดตามผลพร้อมไฟล์ exploit และคำอธิบายไปยัง security@kde.org แต่ไม่ได้รับคำตอบ
  • 2 พฤษภาคม 2026 11:59 ยืนยันว่า exploit ยังไม่ได้รับการแพตช์ใน Plasma 6.7 Beta
  • 2 กรกฎาคม 2026 18:30 เผยแพร่สู่สาธารณะหลัง exploit ยังใช้งานได้และพ้นช่วงรอ 90 วันแล้ว
  • เนื่องจากยังไม่ถูกแพตช์ ไม่ได้รับการตอบกลับติดตาม และเลยช่วงรอ 90 วันตามธรรมเนียมแล้ว ผู้รายงานจึงตัดสินใจเปิดเผยเพื่อสร้างการรับรู้
  • ผู้รายงานเสริมว่าไม่ได้มีเจตนาจะวิจารณ์นักพัฒนา KDE และเข้าใจว่าโครงการ OSS ช่วงหลังเผชิญสแปมมากขึ้น อีกทั้งมนุษย์ก็มีขีดจำกัดด้านกำลังการประมวลผลงาน แต่กระบวนการยังปรับปรุงได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Lobste.rs
  • คงจะดีมากถ้าความพยายามทำ Capsicum สำหรับ Linux ไม่ตายไปเพราะ NIH
    สำหรับการทำ sandbox ให้แอปเดสก์ท็อป มันเป็นโมเดลที่ดีกว่าบรรดาวิธีสารพัดแบบที่ Linux ตอนนี้พยายามต่อเติมขึ้นมาเพื่อทำสิ่งเดียวกันมาก โครงสร้างคือ launcher ส่งชุดสิทธิ์เริ่มต้นตาม metadata หรือก็คือ file descriptor ให้แอป และแอปก็เข้าถึงอย่างอื่นไม่ได้ ส่วน powerbox จะให้สิทธิ์เปิด·บันทึกไฟล์อื่น ๆ
    • โมเดล container ทั้งหมดของ Linux ดูเหมือนการปะติดปะต่อแนวคิดที่ค่อนข้างหยาบ ๆ เข้าด้วยกัน
      โดยทั่วไปมันเหมาะกับสภาพแวดล้อมที่มีโปรเซสระดับเหมือนพระเจ้าคอย orchestrate บริการ เช่นบริการของ Kubernetes แต่ไม่ค่อยเหมาะกับเดสก์ท็อป อยากจะเข้าไปอยู่ใน cgroup/namespace ที่มีสิทธิ์ต่ำกว่าจาก userspace แต่ต้องผ่านพิธีกรรมอย่าง root daemon หรือ setuid สุดท้ายก็เชิญความเสี่ยงเรื่องการยกระดับสิทธิ์เข้ามา
    • ตามทฤษฎีแล้ว เครื่องมือ sandbox เดสก์ท็อปหลัก ๆ ของ Linux อย่าง Flatpak ควรใช้ SCM_RIGHTS + Wayland + D-Bus เป็นองค์ประกอบพื้นฐานและทำงานแบบนี้
      ถ้าหรี่ตามองก็พอเห็นเค้าโครงของเดสก์ท็อปที่ปลอดภัยอยู่
      แต่ implementation จริงโดยรวมแล้วเปิดกว้างเกินไปบ้าง ไม่ยืดหยุ่นบ้าง หรือพังไปครึ่ง ๆ กลาง ๆ ดูเหมือนไม่ค่อยมีใครใส่ใจความปลอดภัยเดสก์ท็อปแบบ end-to-end เท่ากับที่ใส่ใจการดูแลความปลอดภัยของ server workload เลย ดังนั้น gVisor กับ Firecracker จึงทำงานได้ดี แต่ Flatpak กลับรันแอป Gtk+ พื้นฐานสักตัวโดยไม่ทำให้ฟอนต์พังยังยาก และ Wayland compositor ทุกตัวก็ต้อง implement ครึ่งหนึ่งของฐานเดสก์ท็อปที่เชื่อถือได้ขึ้นมาใหม่
      ยิ่งคิดว่า Android ทำหน้าที่เป็นดิสโทร Linux ที่ harden พอจะรันโค้ดที่ไม่น่าเชื่อถือได้ค่อนข้างดี และ iOS กับ macOS ก็แสดงให้เห็นว่า sandbox สำหรับแอปที่ผู้ใช้ใช้งานโดยตรงก็สามารถใช้งานได้สะดวกพอ ยิ่งน่าอาย แค่ทำตามที่พวกเขาทำก็พอแล้ว ทำไมบางอย่างใน window manager ถึงกำลังอ่าน /proc/{pid}/cmdline อยู่กันแน่
  • สถานการณ์ที่ upstream แพตช์ไม่ได้แล้วนำไปสู่การ เปิดเผยต่อสาธารณะ แบบนี้ ดูไม่ดีเลย
    นี่ไม่ได้เป็นการวิจารณ์นักวิจัยแต่อย่างใด
  • ไม่รู้ว่า issue report ที่ส่งไปยัง upstream ก็เป็นแบบนี้ด้วยหรือเปล่า แต่ค่อนข้างตามยาก
    ถ้าคุ้นกับโครงสร้างภายในของ KDE หรือ Flatpak มากกว่านี้ คงเข้าใจได้ดีกว่านี้มาก