พบปัญหาความปลอดภัยหลายรายการใน GNU Screen

 (openwall.com)
2 คะแนน โดย GN⁺ 2025-05-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การตรวจสอบความปลอดภัยของ GNU Screen พบการยกระดับสิทธิ์ภายในเครื่อง, การไฮแจ็ก TTY, การเปิดเผยข้อมูล, เงื่อนไขการแข่งขันในการส่งสัญญาณ และการแครชจากการส่งคำสั่ง โดยมีจุดเน้นที่ Screen 5.0.0 และการติดตั้งแบบ setuid-root
  • รายการที่ร้ายแรงที่สุดคือ CVE-2025-23395 ซึ่ง logfile_reopen() ประมวลผลพาธที่ผู้ใช้ป้อนด้วยสิทธิ์ root ทำให้สามารถสร้างไฟล์ที่มีเจ้าของเป็น root ในตำแหน่งใดก็ได้ หรือผนวกล็อกเข้ากับไฟล์ที่มีอยู่แล้วได้
  • พฤติกรรมเก่าของโหมดหลายผู้ใช้ก็ถูกพบว่าเป็นปัญหาเช่นกัน โดย Attach() เปลี่ยน TTY เป็น 0666 ชั่วคราว ทำให้ผู้ใช้อื่นสามารถอ่าน·เขียนและฉีดอินพุตได้
  • ความเสี่ยงของแต่ละดิสทริบิวชันแตกต่างกันตามวิธีติดตั้ง โดย Arch Linux และ NetBSD 10.1 จัดส่ง Screen 5.0.0 แบบ setuid-root จึงได้รับผลกระทบจากช่องโหว่หลักมาก
  • คำแนะนำปัจจุบันคือไม่ควรติดตั้ง Screen แบบ setuid-root และฟีเจอร์หลายผู้ใช้ควรเป็นแบบ opt-in บนฐานกลุ่มที่เชื่อถือได้ พร้อมลดสิทธิ์เริ่มต้น, ยกระดับสิทธิ์อย่างจำกัด และล้างตัวแปรสภาพแวดล้อม

เบื้องหลังการเปิดเผยและแพตช์

  • ในเดือนกรกฎาคม 2024 ผู้ดูแล upstream ของ Screen ขอให้ตรวจสอบโค้ดเบสปัจจุบัน และการตรวจสอบความปลอดภัยจริงเริ่มขึ้นในเดือนมกราคม 2025
  • ผลการตรวจสอบพบ exploit ยกระดับเป็น root ภายในเครื่องในอัปเดตใหญ่ของ Screen 5.0.0 ซึ่งกระทบดิสทริบิวชันที่แจกจ่ายแบบ setuid-root
  • ยังพบปัญหาความรุนแรงต่ำกว่าเพิ่มเติม โดยบางส่วนกระทบ Screen 4.9.1 และเวอร์ชันก่อนหน้า ที่ยังคงอยู่ในหลายดิสทริบิวชัน
  • ปัญหาเหล่านี้ถูกแชร์ไปยังเมลลิงลิสต์ distros เมื่อวันที่ 30 เมษายน 2025 และเปิดเผยต่อสาธารณะเมื่อวันที่ 12 พฤษภาคม 2025
  • รายงานแนบชุดแพตช์แยกตามเวอร์ชัน

โครงสร้างของ Screen และโหมดหลายผู้ใช้

  • Screen 5.0.0 เปิดตัวเป็นรีลีสหลักจาก upstream ในเดือนสิงหาคม 2024 และ Arch Linux, Fedora 42, NetBSD 10.1 จัดส่งเวอร์ชันนี้
  • ดิสทริบิวชัน Linux และ UNIX จำนวนมากยังคงใช้ Screen 4.9.1 ณ เวลาที่เขียน
  • โหมดหลายผู้ใช้ ของ Screen อนุญาตให้ attach เข้ากับเซสชัน Screen ที่ผู้ใช้อื่นเป็นเจ้าของได้เมื่อมีข้อมูลรับรองที่เหมาะสม
    • ฟีเจอร์นี้ใช้ได้เฉพาะเมื่อ Screen ติดตั้งด้วยบิต setuid-root เท่านั้น
    • โค้ด Screen ที่ซับซ้อนทำงานด้วยสิทธิ์ root จึงเพิ่มพื้นผิวการโจมตี
  • ในระบบที่ตรวจสอบ Arch Linux, FreeBSD, NetBSD ติดตั้ง Screen แบบ setuid-root
  • Gentoo Linux จะใช้บิต setuid-root เมื่อเปิด USE flag "multiuser"
  • บางดิสทริบิวชันใช้ setgid แทน setuid
    • ค่าเริ่มต้นของ Gentoo Linux คือ setgid-utmp ทำให้ Screen สร้างบันทึกล็อกอินในฐานข้อมูล utmp ทั่วระบบได้
    • Fedora Linux ใช้ setgid-screen ทำให้ Screen วางซ็อกเก็ตไว้ในไดเรกทอรีทั่วระบบ /run/screen ได้

CVE-2025-23395: exploit root ภายในเครื่องผ่าน logfile_reopen()

  • CVE-2025-23395 ส่งผลกระทบเมื่อ Screen 5.0.0 ทำงานด้วยสิทธิ์ setuid-root
  • ฟังก์ชัน logfile_reopen() ไม่ลดสิทธิ์ขณะประมวลผลพาธที่ผู้ใช้ป้อน
  • ผู้ใช้ที่ไม่มีสิทธิ์พิเศษสามารถสร้างไฟล์ที่มีคุณสมบัติต่อไปนี้ในตำแหน่งใดก็ได้
    • เจ้าของ: root
    • กลุ่ม: กลุ่มจริงของผู้ใช้ที่เรียกใช้
    • โหมดไฟล์: 0644
  • ไฟล์ที่มีอยู่แล้วก็สามารถถูกใช้โจมตีได้
    • ข้อมูลที่เขียนไปยัง Screen PTY จะถูก append เข้ากับไฟล์นั้น
    • โหมดและเจ้าของของไฟล์เดิมจะไม่ถูกเปลี่ยน
  • Screen ลดสิทธิ์อย่างถูกต้องเมื่อเปิดไฟล์ล็อกครั้งแรก แต่เมื่อใดก็ตามที่ตัดสินใจว่าต้องเปิดไฟล์ล็อกใหม่ จะเกิดโอกาสยกระดับสิทธิ์
  • ในการตรวจ stolen_logfile() หาก link count ของไฟล์ล็อกเดิมกลายเป็น 0 หรือขนาดเปลี่ยนไปอย่างไม่คาดคิด จะเรียก logfile_reopen()
  • ผู้ใช้ที่ไม่มีสิทธิ์พิเศษสามารถจงใจทำให้เกิดเงื่อนไขนี้ได้
  • patch 0001 สำหรับ Screen 5.0.0 นำการจัดการไฟล์อย่างปลอดภัยกลับมาใช้ในกระบวนการ reopen ไฟล์ล็อก
  • ปัญหานี้เกิดจาก commit เก่า 441bca708bd ที่ลบ lf_secreopen() ออก และการเปลี่ยนแปลงดังกล่าวถูกรวมอยู่ในรีลีส 5.0.0

CVE-2025-46802: การไฮแจ็ก TTY ระหว่าง attach เซสชันหลายผู้ใช้

  • CVE-2025-46802 เกิดในฟังก์ชัน Attach() เมื่อมีการตั้งค่าแฟล็ก multiattach
  • เมื่อ attach เข้ากับเซสชันหลายผู้ใช้ Screen จะใช้ chmod() เปลี่ยนโหมดของ TTY ปัจจุบันเป็น 0666
  • พาธ TTY ถูกตรวจสอบว่าอยู่ใต้ /dev และเงื่อนไข isatty() เป็นต้น ดังนั้นพฤติกรรมนี้อย่างเดียวจึงยังไม่กลายเป็น exploit root ภายในเครื่องแยกต่างหาก
  • ปัญหาคือในช่วงที่สิทธิ์ TTY ถูกผ่อนคลายชั่วคราว จะเกิด เงื่อนไขการแข่งขัน ที่ทำให้ผู้ใช้อื่นอ่านและเขียน TTY นั้นได้
  • ในการทดสอบง่าย ๆ ที่ใช้ Linux inotify API สคริปต์ Python สามารถเปิด TTY ที่ได้รับผลกระทบได้ทุก ๆ สองหรือสามครั้งที่ลอง
  • ผู้โจมตีสามารถทำสิ่งต่อไปนี้ได้
    • ดักข้อมูลที่พิมพ์เข้า TTY
    • ฉีดข้อมูลเข้า TTY
    • หลอกให้ผู้ใช้ป้อนรหัสผ่าน
    • ฉีด control sequence เพื่อทำให้เหยื่อสับสน หรือโจมตีปัญหาที่เกี่ยวข้องใน terminal emulator
  • ในบางเส้นทาง return ของ Attach() โหมด TTY เดิมจะไม่ถูกคืนค่า
    • ตัวอย่าง: หาเซสชันเป้าหมายไม่พบและตั้งค่าอาร์กิวเมนต์ "quiet"
  • แพตช์ลบ chmod() ชั่วคราวออก
    • patch 0001 สำหรับ Screen 4.9.1
    • patch 0004 สำหรับ Screen 5.0.0
  • ก่อนเปิดเผยไม่นาน พบว่าแพตช์นี้อาจทำให้กรณีใช้งาน reattach บางแบบเสีย แต่ยืนยันแล้วว่ากรณีใช้งานนั้นเสียอยู่แล้วใน Screen 4.9.1
  • ปัญหานี้มีอยู่ใน Screen อย่างน้อยตั้งแต่ปี 2005 และกระทบ Linux ดิสทริบิวชันกับ BSD ที่ให้การรองรับหลายผู้ใช้แบบ setuid-root
  • แม้ไม่ใช่ setuid-root ก็อาจได้รับผลกระทบในเชิงทฤษฎี เพราะผู้ใช้มีสิทธิ์เปลี่ยนโหมด TTY ของตนเอง แต่ Screen จะไม่ดำเนินการต่อกับเซสชันของผู้ใช้อื่นโดยไม่มีสิทธิ์ root

CVE-2025-46803: ค่าเริ่มต้น PTY แบบ world-writable ใน Screen 5.0.0

  • CVE-2025-46803 คือปัญหาที่โหมดเริ่มต้นของ PTY ที่ Screen จัดสรรใน Screen 5.0.0 เปลี่ยนจาก 0620 เป็น 0622
  • ด้วยค่าเริ่มต้นนี้ ทุกคนในระบบสามารถเขียนไปยัง Screen PTY ได้
  • ด้านความปลอดภัยจะเกิดปัญหาคล้าย CVE-2025-46802 แต่ไม่รวมประเด็นการรั่วไหลของข้อมูล
  • ใน Screen 4.9.1 ค่าเริ่มต้นระดับโค้ดคือ 0622 แต่ค่าเริ่มต้น 0620 จากการกำหนดค่า autotools ถูกนำมาใช้ จึงได้ค่าเริ่มต้นที่ปลอดภัย
  • ใน Screen 5.0.0 มีการเขียน configure.ac ใหม่ ทำให้ค่าเริ่มต้น 0620 ระดับ autoconf หายไป และภายหลังสวิตช์ configure pty-mode ถูกนำกลับมาโดยมีค่าเริ่มต้นเป็น 0622
  • ไม่พบ release note ของ 5.0.0 และมีเพียงบางรายการใน ChangeLog โดยการเปลี่ยนค่าเริ่มต้นโหมด PTY ดูไม่น่าจะเป็นการตัดสินใจโดยตั้งใจ
  • patch 0002 สำหรับ Screen 5.0.0 คืนค่าโหมด PTY เริ่มต้นที่ปลอดภัยใน configure.ac
    • ต้องรัน autoreconf เพื่อให้การเปลี่ยนแปลงมีผล
  • แนะนำให้ผู้จัดทำแพ็กเกจส่งสวิตช์ configure --with-pty-mode=0620 อย่างชัดเจน
  • Gentoo Linux และ Fedora Linux ส่ง --with-pty-mode ที่ปลอดภัยอย่างชัดเจน
  • Arch Linux และ NetBSD ไม่ได้ส่งสวิตช์ดังกล่าว จึงใช้ค่าเริ่มต้นใหม่และมีช่องโหว่

CVE-2025-46804: การเปิดเผยว่ามีไฟล์อยู่หรือไม่ผ่านข้อความผิดพลาดของพาธซ็อกเก็ต

  • CVE-2025-46804 เป็นการเปิดเผยข้อมูลเล็กน้อยที่เกิดเมื่อ Screen ทำงานด้วยสิทธิ์ setuid-root
  • พบทั้งใน Screen เวอร์ชันเก่าและ 5.0.0
  • Screen ตรวจสอบ SocketPath ด้วยสิทธิ์ root และเปิดเผยข้อมูลพาธที่ผู้ใช้ไม่มีสิทธิ์ปกติจะรู้ได้ผ่านข้อความผิดพลาด
  • เมื่อใช้ตัวแปรสภาพแวดล้อม SCREENDIR สามารถอนุมานข้อมูลต่อไปนี้ได้
    • /root/.lesshst เป็นไฟล์ปกติหรือไม่
    • มีไดเรกทอรี /root/.cache อยู่หรือไม่
    • พาธ /root/test ไม่มีอยู่หรือไม่
  • แพตช์เปลี่ยนให้ในการติดตั้งแบบ setuid-root แสดงเฉพาะข้อความผิดพลาดทั่วไปเมื่อพาธเป้าหมายไม่ได้ถูกควบคุมโดย UID จริงของโปรเซส
    • patch 0002 สำหรับ Screen 4.9.1
    • patch 0005 สำหรับ Screen 5.0.0
  • ดิสทริบิวชันทั้งหมดที่ตรวจสอบได้รับผลกระทบ

CVE-2025-46805: เงื่อนไขการแข่งขัน TOCTOU ในการส่งสัญญาณ

  • CVE-2025-46805 เป็นเงื่อนไขการแข่งขันแบบ TOCTOU ที่เกิดเมื่อส่งสัญญาณไปยัง PID ที่ผู้ใช้ป้อนในบริบท setuid-root
  • CheckPid() ลดสิทธิ์เป็น user ID จริง แล้วตรวจว่าเคอร์เนลอนุญาตให้ส่งสัญญาณไปยัง PID เป้าหมายหรือไม่
  • สัญญาณจริงจะถูกส่งภายหลังผ่าน Kill() และในตอนนั้นอาจใช้สิทธิ์ root
  • ระหว่างการตรวจสอบกับการส่งจริง PID ที่เคยตรวจสอบแล้วอาจถูกแทนที่ด้วย privileged process อื่น
  • อาจหลอกให้ privileged Screen daemon process ส่งสัญญาณให้ตัวเองได้ด้วย
  • ปัจจุบันส่งได้เฉพาะ SIGCONT และ SIGHUP จึงน่าจะมีผลกระทบในขอบเขต local denial of service หรือการละเมิดความสมบูรณ์เล็กน้อย
  • ปัญหานี้มีต้นเหตุมาจากการแก้ไข CVE-2023-24626 ที่ไม่สมบูรณ์
    • ก่อนการแก้ไขนั้น สามารถส่งสัญญาณดังกล่าวไปยังกระบวนการใดก็ได้โดยไม่ต้องอาศัยเงื่อนไขการแข่งขัน
  • แพตช์เปลี่ยนให้ส่งสัญญาณจริงด้วยสิทธิ์ UID จริงเช่นเดียวกับ CheckPid()
    • patch 0003 สำหรับ Screen 4.9.1
    • patch 0006 สำหรับ Screen 5.0.0
  • ดิสทริบิวชันทั้งหมดที่ตรวจสอบได้รับผลกระทบ

การแครชจากการส่งคำสั่งเนื่องจากการใช้ strncpy() ใน Screen 5.0.0

  • Screen 5.0.0 มีปัญหาเกี่ยวกับ strncpy() ที่ไม่ถือเป็นประเด็นความปลอดภัย แต่ควรแก้ไขก่อน
  • ใน commit 0dc67256 มีการแทนที่การเรียก strcpy() หลายจุดด้วย strncpy()
  • strncpy() ไม่ใช่ฟังก์ชันสำหรับจัดการสตริงอย่างปลอดภัย แต่เป็นฟังก์ชันที่ padding บัฟเฟอร์ความยาวคงที่ด้วย 0 ดังนั้นหลังไบต์ \0 แรกแล้วก็ยังเขียน 0 ไปจนสุดบัฟเฟอร์ปลายทาง
  • ในลูปประมวลผลอาร์กิวเมนต์ command line ของ attacher.c หลังจากรอบแรกแล้วยังส่ง MAXPATHLEN เป็นขนาดปลายทางอยู่
  • แม้พอยน์เตอร์ p จะถูกเพิ่มค่าไปแล้ว แต่ยังส่งขนาดเดิม ทำให้การเรียก strncpy() ในรอบถัดไปเขียนไบต์ \0 เลยท้ายบัฟเฟอร์
  • บน Arch Linux เมื่อส่งอาร์กิวเมนต์คำสั่งมากกว่าหนึ่งรายการไปยังเซสชัน Screen ที่กำลังรันอยู่ จะพบข้อผิดพลาดต่อไปนี้ในบิลด์ที่เปิด _FORTIFY_SOURCE
    • *** buffer overflow detected***: terminated
    • Aborted (core dumped)
  • หากไม่มี _FORTIFY_SOURCE อาจไม่เห็นข้อผิดพลาด และแม้ใช้ -fsanitize=address ก็อาจไม่เห็นข้อผิดพลาดเช่นกัน
  • ผู้เรียกสามารถเขียนทับ 0 เป็นจำนวน MAXPATHLEN ไบต์หลังบัฟเฟอร์ cmd ได้ แต่เนื่องจากมีบัฟเฟอร์ writeback[MAXPATHLEN] ขนาดเท่ากันอยู่ถัดไป จึงประเมินว่าไม่น่าถูกโจมตีในทางที่เป็นประโยชน์ต่อผู้โจมตีได้
  • patch 0003 สำหรับ Screen 5.0.0 เปลี่ยน strncpy() เป็น snprintf() และส่งขนาดบัฟเฟอร์ปลายทางที่เหลืออยู่อย่างถูกต้อง
  • ดิสทริบิวชันทั้งหมดที่จัดส่ง Screen 5.0.0 ได้รับผลกระทบ

ขอบเขตผลกระทบแยกตามดิสทริบิวชัน

ระบบ เวอร์ชัน Screen สิทธิ์พิเศษ ผลกระทบ
Arch Linux 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10 4.9.0 ไม่มี 3.b บางส่วน
Ubuntu 24.04.2 4.9.1 ไม่มี 3.b บางส่วน
Fedora 42 5.0.0 setgid-screen 3.b บางส่วน, 3.f
Gentoo 4.9.1 setgid-utmp, setuid-root เมื่อตั้งค่า multiuser USE flag 3.b บางส่วน
openSUSE TW 4.9.1 ไม่มี 3.b บางส่วน
FreeBSD 14.2 4.9.1 setuid-root 3.b, 3.d, 3.e
NetBSD 10.1 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7 4.9.1 ไม่มี 3.b บางส่วน

ข้อกังวลและคำแนะนำต่อการออกแบบ setuid-root

  • โหมดหลายผู้ใช้ของ Screen เกี่ยวข้องกับ UID สามประเภท
    • effective UID 0 สำหรับ privileged operation
    • UID จริงของผู้ใช้ที่สร้างเซสชัน
    • UID จริงของผู้ใช้ที่ attach เข้ากับเซสชัน
  • โค้ด Screen ปัจจุบันดูมีโครงสร้างที่สะท้อนความแตกต่างนี้ได้ยากอย่างเหมาะสม
  • เซสชันหลายผู้ใช้ของ Screen ที่สร้างโดย root จะ “ลดสิทธิ์” ไปเป็น UID จริง 0 ของผู้สร้างเซสชัน ดังนั้นในทางปฏิบัติไม่ได้เกิดการลดสิทธิ์
  • ระหว่างการ refactor ใน Screen 5.0.0 ตรรกะด้านความปลอดภัยที่มีมายาวนานเสียหาย ส่งผลให้เกิด CVE-2025-23395 และ CVE-2025-46803
  • ก่อน refactor เพิ่มเติม จำเป็นต้องมี test suite ที่ตรวจสอบคุณสมบัติด้านความปลอดภัยของ implementation ได้
  • นักพัฒนาที่ดูแลไบนารี setuid-root ต้องเข้าใจความเสี่ยงในบริเวณนี้
  • Screen รันต่อไปด้วยสิทธิ์ที่ยกระดับ แล้วลดสิทธิ์แบบเลือกเฉพาะในงานที่มองว่าเสี่ยง
  • โปรแกรม setuid-root ที่แข็งแรงควรลดสิทธิ์โดยค่าเริ่มต้น และยกระดับสิทธิ์เฉพาะเมื่องานนั้นต้องใช้สิทธิ์สูงจริง ๆ
  • ในบริบท setuid-root ต้องมีตรรกะที่ลบตัวแปรสภาพแวดล้อมออก เหลือเฉพาะตัวที่อนุญาตอย่างชัดเจน
  • ตัวแปรสภาพแวดล้อมอย่าง PATH ควรถูกจัดให้ชี้เฉพาะไดเรกทอรีระบบที่เชื่อถือได้
  • ปัจจุบันแนะนำว่าไม่ควรติดตั้งแบบ setuid-root ทั้ง Screen 5.0.0 และสาย 4.9 รุ่นก่อนหน้า
  • อีกทางเลือกหนึ่งคือให้ฟีเจอร์หลายผู้ใช้เป็นแบบ opt-in และอนุญาตเฉพาะสมาชิกกลุ่มที่เชื่อถือได้ให้รัน Screen เวอร์ชันหลายผู้ใช้

กระบวนการประสานการเปิดเผยและสถานะ upstream

  • ในเดือนกุมภาพันธ์ 2025 มีการรายงานปัญหาแบบไม่สาธารณะต่อ upstream ของ Screen และเสนอการเปิดเผยแบบประสานงาน
  • upstream แสดงความสนใจที่จะเก็บปัญหาเป็นความลับเพื่อแก้บั๊กก่อนเปิดเผย และแจ้งว่าต้องใช้เวลา 1–2 เดือน
  • ประมาณหนึ่งเดือนต่อมา เริ่มมีกิจกรรมและการหารือเรื่องแพตช์จากฝั่ง upstream แต่การหารือไม่ได้เกิดผลมากพอ
  • จนใกล้ครบช่วง embargo สูงสุด 90 วัน ก็ไม่มีการสื่อสารเพิ่มเติม และระหว่างนั้นดิสทริบิวชันอย่าง NetBSD อัปเดตเป็น Screen 5.0.0 จนได้รับผลกระทบเต็มจาก CVE-2025-23395
  • มีการประเมินว่า upstream ยังไม่คุ้นเคยกับโค้ดเบส Screen เพียงพอ และไม่เข้าใจปัญหาความปลอดภัยที่รายงานอย่างถ่องแท้
  • upstream ต้องการเปิดเผยเร็วขึ้นทั้งที่บางปัญหายังไม่ได้แก้ จึงส่งฉบับร่างไปยังเมลลิงลิสต์ distros อย่างรวดเร็ว
  • หลังจากนั้นฝั่ง SUSE พัฒนาการแก้ไขที่ขาดหายไปเอง และปรับแต่งพร้อมจัดทำเอกสารแพตช์ที่เคยหารือในรูปแบบร่างกับ upstream
  • ประเมินว่าหากมีขีดความสามารถ upstream เฉพาะทาง กระบวนการเปิดเผยแบบประสานงานน่าจะเสร็จได้ภายในประมาณ 2 สัปดาห์
  • upstream ของ Screen ดูเหมือนกำลังขาดทั้งกำลังคนและความเชี่ยวชาญ ซึ่งน่ากังวลเพราะเป็นยูทิลิตีโอเพนซอร์สที่ใช้งานกันอย่างแพร่หลาย

ไทม์ไลน์สำคัญ

  • 2024-07-01: ได้รับคำขอตรวจสอบจาก upstream
  • 2025-01-08: เริ่มงานตรวจสอบความปลอดภัย
  • 2025-02-07: รายงานแบบไม่สาธารณะต่อ upstream ของ Screen และเสนอการเปิดเผยแบบประสานงาน
  • 2025-02-11: สร้างบั๊กแบบไม่สาธารณะใน GNU Savannah bug tracker
  • 2025-04-30: ตัดสินใจกำหนด CVE และแชร์ฉบับร่างไปยังเมลลิงลิสต์ distros
  • 2025-05-07: แชร์แพตช์ฉบับสมบูรณ์สำหรับ Screen 4.9.1 และ 5.0.0 ไปยังเมลลิงลิสต์ distros และ upstream
  • 2025-05-12: รายงานถูกเผยแพร่ในบล็อกและเมลลิงลิสต์ oss-security

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

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

 
GN⁺ 2025-05-14
ความคิดเห็นใน Hacker News

  • ไม่เคยรู้มาก่อนว่า Screen มี โหมดผู้ใช้หลายคน แบบนี้ แต่ก็คงเป็นฟีเจอร์นี้เองที่ทำให้เครื่องมืออย่าง tmate ใช้งานได้
    ว่ากันว่าถ้ามีข้อมูลยืนยันตัวตนที่เหมาะสม ก็สามารถเข้าไปแนบกับเซสชัน Screen ที่ผู้ใช้อื่นเป็นเจ้าของได้ และฟีเจอร์นี้จะใช้ได้ก็ต่อเมื่อติดตั้ง Screen แบบ setuid-root เท่านั้น
    เลยสงสัยว่า tmux จะได้รับผลกระทบจากช่องโหว่ประเภทเดียวกันหรือไม่

    • tmux ไม่ได้รับผลกระทบ เพราะใช้ Unix domain socket
      ไม่รู้เหมือนกันว่าทำไม screen ถึงเลือกวิธี setuid ในกรณีนี้ และก็ดูเหมือนไม่จำเป็นต้องใช้สิทธิ์ root เลย
      ถ้าเลื่อนลงไปด้านล่างของบทความจะมีคำอธิบายที่ฟังขึ้นว่า นักพัฒนา screen ในปัจจุบันอาจยังไม่คุ้นกับ codebase อย่างเต็มที่ ดังนั้นวิธีที่ง่ายที่สุดในการทำให้ฟีเจอร์นี้ทำงานได้อาจเป็นการใช้ setuid-root
    • เป็นฟีเจอร์ที่ยอดเยี่ยมพอสมควร
      ตอนทำเซสชันสอนเคยให้บัญชีล็อกอินบนโน้ตบุ๊กของตัวเองกับนักเรียนแต่ละคน จำกัด SSH shell ให้ใช้ screen -x แล้วใช้ access control list ของ screen เพื่อให้นักเรียนแต่ละคนใช้ได้เฉพาะหน้าต่างของตัวเอง
      ระหว่างทำแล็บ ฉันในฐานะเจ้าของ screen สามารถฉายหน้าจอของนักเรียนแต่ละคนขึ้นโปรเจ็กเตอร์ให้ทั้งห้องดูผลลัพธ์ได้
      จะมีช่องโหว่ด้านความปลอดภัยเยอะก็ไม่น่าแปลกใจ
    • ใช่แล้ว screen -x

  • บน Debian นั้น GNU screen ไม่ได้ถูกติดตั้งด้วยสิทธิ์ setuid-root

    • แพ็กเกจใน Debian Stable หรือ bookworm นั้นเก่าเกินกว่าจะได้รับผลกระทบจาก ช่องโหว่ใน 5.0.0
      เมื่อก่อนฉันไม่ชอบเลยที่ Debian มักตามหลังเรื่องเวอร์ชันซอฟต์แวร์ แต่ตอนนี้กลับอยู่กับแพ็กเกจเก่าได้สบาย ยกเว้นบางแอปอย่างเบราว์เซอร์ที่ไม่อยากพึ่งซอฟต์แวร์เก่ามากจริง ๆ จึงค่อยใช้แหล่งแพ็กเกจอื่น
    • ใน Slackware 15 นั้น /usr/bin/screen ชี้ไปที่ screen-4.9.0 และตัวไบนารีก็ไม่ใช่ suid
    • Gentoo ก็เหมือนกัน
      แต่ใน Gentoo มี SETGID สำหรับกลุ่ม utmp อยู่ด้วย ซึ่งไม่แน่ใจว่ามีผลอย่างไร
    • บน Fedora ดูเหมือนจะเป็น setuid-root

  • บทความบล็อกฉบับเรนเดอร์อยู่ที่นี่: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • เคยส่งอีเมลไปหาผู้เขียน GNU Screen ว่า ฟีเจอร์บันทึกไฟล์ มีเอกสารไม่ดีพอ: http://www.zoobab.com/screenrc
    GNU ควรมีระบบติดตาม issue ที่ดีกว่านี้

    • เคยมี Q&A กับผู้เขียน Tmux ซึ่งแม้แต่เมื่อราว 16 ปีก่อนก็ยังบ่นเรื่อง เอกสารไม่เพียงพอ อยู่
      https://undeadly.org/cgi?action=article&sid=20090712190402
    • มีเอกสารไว้อย่างละเอียดในคู่มือ GNU screen: https://www.gnu.org/software/screen/manual/screen.html#Log
    • หลายโปรเจ็กต์เก่าเจอปัญหาที่ issue ถูกฝังหายไปในความลึกไม่รู้จบของเมลลิงลิสต์ที่ไม่ได้ทำดัชนี
      การวิจารณ์ว่า Discord ทำให้ข้อมูลประเภทนี้เข้าถึงไม่ได้ก็สมเหตุสมผล แต่ IRC ที่บางโปรเจ็กต์ยังใช้อยู่ทุกวันนี้จริง ๆ แล้วแย่กว่านั้นประมาณสองเท่า
      อยากให้โปรเจ็กต์เหล่านี้ย้ายไปอยู่บน Gitea, Forgejo, Codeberg, GitLab หรือ GitHub เพื่อรวมเรื่องที่เกี่ยวข้องไว้ที่เดียวและทำให้ ค้นพบได้ง่ายขึ้น

  • Zellij เป็น ทางเลือกสมัยใหม่ ของ screen และ tmux ที่ค่อนข้างดี ค่าเริ่มต้นก็ดีมาก และทำ UI ให้ค้นพบได้ง่าย
    แนะนำสำหรับคนที่รู้สึกว่า terminal multiplexer ให้ผลลัพธ์ไม่คุ้มกับความพยายามที่จะเรียนรู้
    https://zellij.dev
    https://github.com/zellij-org/zellij

    • เคยใช้เมื่อสองสามปีก่อนและรู้สึกว่าลื่นดีมาก
      แต่เทียบกับ tmux แล้ว latency สังเกตได้ชัด และตอนนี้ก็ยังใช้ tmux ต่อไป
      ตอนนั้นฉันใช้การเชื่อมต่อที่มี latency อยู่แล้วด้วย เลยอาจจะไวต่อเรื่องนี้เป็นพิเศษ
    • ครั้งล่าสุดที่ดู Zellij มันดูเป็นโปรเจ็กต์ใหม่ที่ยอดเยี่ยมใน ecosystem ของ multiplexer แต่ยังไม่รองรับกลไก คัดลอก/วางด้วยคีย์บอร์ดล้วน
      ฉันใช้ฟีเจอร์นั้นบ่อยมาก เลยขาดมันไม่ได้ และจนกว่าจะมีเพิ่มเข้ามาก็คงต้องใช้ tmux ต่อไป
    • มันดีนะ แต่ฉันชอบ screen มากจริง ๆ และคำสั่งต่าง ๆ ก็เข้า ความจำของกล้ามเนื้อ ไปแล้ว
      ใช้มานานกว่า 20 ปี

  • แปลกใจที่ upstream เข้ามาเกี่ยวข้องกับเรื่องนี้
    เมื่อราว 5 ปีก่อนฉันสรุปอย่างเศร้าว่าการพัฒนา GNU screen หยุดไปอย่างสิ้นเชิงแล้ว เลยสงสัยว่าตอนนี้ยังไม่ถึงขั้นนั้นหรือเปล่า
    ไม่รู้ว่า screen ยังมีฟีเจอร์ เพิ่มหน้าต่างใหม่ โดยไม่แนบเข้ากับ screen เดิมอยู่หรือไม่

    • upstream เป็นฝ่ายขอให้ทีม SUSE ช่วยตรวจสอบ
      ดูเหมือนว่าขาดกำลังคนพัฒนา และ upstream เองอาจไม่มีความเชี่ยวชาญพอจะบำรุงรักษาได้อย่างเหมาะสม
      ถ้าเป็นจริงก็น่าเศร้า แม้จะรู้ว่ามี tmux และทางเลือกอื่น ๆ แต่หลายคนก็ใช้ Screen กันมานานมาก และน่าเสียดายถ้าเครื่องมือค่อย ๆ เสื่อมสภาพลง
    • มีการระบุว่าเนื่องจากสื่อสารกับ upstream ได้ยาก จึงยังไม่มีข้อมูลรายละเอียดเกี่ยวกับการแก้บั๊กและรีลีสที่ upstream ออกมาในตอนนี้
      เหมือนจะมีการขอให้ช่วยตรวจสอบด้านความปลอดภัย แต่ยากที่จะติดต่อกันอย่างต่อเนื่อง รายละเอียดทั้งหมดเป็นอย่างไรยังไม่แน่ชัด
    • ถ้าจะเรียกว่าเกี่ยวข้อง ก็แค่ในแง่ที่ปล่อยแพ็กเกจมาแบบ setuid-root
      ดิสทริบิวชันที่ตั้งค่าแบบนี้จึงมีช่องโหว่ ส่วนดิสทริบิวชันที่ไม่ตั้งค่าแบบนี้ก็ไม่โดน
      ถือว่าเกี่ยวข้องแค่ผิวเผินมาก ถ้า upstream ช้าเกินไป ดิสทริบิวชันก็แพตช์กันเอง
    • การพัฒนาเครื่องมือของ GNU หยุดลงก็ไม่ได้แปลว่าน่าเศร้าเสมอไป แน่นอนว่าไม่นับเรื่องการแก้บั๊ก
      โดยพื้นฐานแล้วอาจมองได้ว่าเป็นสัญญาณของ เครื่องมือที่เสร็จสมบูรณ์แล้ว
    • ในโอเพนซอร์สมีปัญหาเรื่องแรงเฉื่อยตอนซอฟต์แวร์หนึ่งสิ้นสุดลงและมีซอฟต์แวร์ตัวอื่นถูกสร้างขึ้นมาแทน
      ไม่มีแรงจูงใจให้เปลี่ยนทันที เพราะมันไม่ใช่การอัปเดตแต่เป็นการย้าย
      ในทางกลับกัน ถ้ามีใครมาซื้อเครื่องหมายการค้าของซอฟต์แวร์เดิมแล้วเปลี่ยนมันเป็นอย่างอื่นไปเลยเหมือนกรณี Audacity ก็แย่เหมือนกัน
      เลยดูเหมือนจะไม่มีทางออกที่ดีนัก

  • เวอร์ชันเรนเดอร์: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • ถ้าจำไม่ผิด tmux ถูกรวมอยู่ใน base system ของ OpenBSD ตั้งแต่ 4.6 และเป็นเครื่องมือที่ผ่านหรือกำลังผ่านการตรวจสอบความปลอดภัย
    เหมาะกับคนที่ต้องการทางเลือกที่ปลอดภัยกว่าเล็กน้อย

    • พอเห็น screen กลับมาอีกครั้ง ก็ทำให้นึกถึงช่วงที่ครั้งหนึ่งเคยเปลี่ยนไปใช้ tmux แล้วลืม screen ไปเลย

  • พฤติกรรมที่สังเกตพบมีอยู่ใน Screen เวอร์ชันต่าง ๆ อย่างน้อยตั้งแต่ปี 2005 และถือเป็น anti-pattern มานานขนาดนั้น โดยเครื่องมืออย่าง rkhunter ก็จัดการกับเรื่องนี้มาแล้ว
    ถึงอย่างนั้น screen ก็ดูเหมือนจะเป็น setuid root มาตั้งแต่ยุค 90 อยู่แล้ว

  • เครื่องมือโอเพนซอร์สที่ได้รับความนิยมที่สุด จริง ๆ แล้วมีนักพัฒนากี่คนที่ดูแลอยู่?
    และในอุตสาหกรรมที่ใช้งานเครื่องมือเหล่านั้น มีเงินหมุนเวียนอยู่มากแค่ไหน?