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

• พบช่องโหว่ความปลอดภัยร้ายแรงใน GNU Screen 5.0.0 และการติดตั้งแบบ setuid-root
• ประเด็นหลักได้แก่ การยกระดับสิทธิ์เป็น root จากเครื่องภายใน, การจี้ TTY, การสร้าง PTY ที่เขียนได้โดยทุกคน
• ดิสทริบิวชัน Linux และ UNIX จำนวนมากได้รับผลกระทบบางส่วนหรือทั้งหมด
• มีการจัดทำ แพตช์ชั่วคราว และหลายดิสทริบิวชันจำเป็นต้องเร่งดำเนินการก่อน
• ตัวการออกแบบ setuid-root ของ Screen เองมี ความเสี่ยงด้านความปลอดภัยเชิงโครงสร้าง

---

1. บทนำ

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

2. ภาพรวมการตั้งค่าและเวอร์ชันของ Screen

• เดือนสิงหาคม 2024 มีการออก Screen 5.0.0 และถูกรวมใน Arch Linux, Fedora 42, NetBSD 10.1
• 5.0.0 มีการ refactoring จำนวนมาก และบางส่วนเป็นโค้ดที่มีอยู่มานานกว่า 10 ปี
• ช่องโหว่บางรายการเพิ่งถูกนำเข้ามาใน 5.0.0 ขณะที่บางรายการมีอยู่แล้วใน เวอร์ชันก่อนหน้า (เช่น 4.9.1)
• ดิสทริบิวชันส่วนใหญ่ยังคงใช้ 4.9.1
• โหมดหลายผู้ใช้ของ Screen ใช้งานได้เฉพาะเมื่อติดตั้งแบบ setuid-root เท่านั้น และด้วยความซับซ้อนของโค้ดทำให้พื้นผิวการโจมตีเพิ่มขึ้นมาก
• ในบรรดาดิสทริบิวชันหลัก Arch Linux, FreeBSD, NetBSD ติดตั้ง Screen แบบ setuid-root; ส่วน Gentoo สามารถติดตั้งแบบ setuid-root ได้เฉพาะเมื่อใช้แฟลก USE “multiuser”

3. รายละเอียดประเด็นความปลอดภัย

3.a) การได้สิทธิ์ root ภายในเครื่องผ่าน logfile_reopen() (CVE-2025-23395)

• เมื่อรัน Screen 5.0.0 แบบ setuid-root ฟังก์ชัน logfile_reopen() จะสร้างไฟล์จากพาธที่ผู้ใช้ป้อนโดยไม่ลดสิทธิ์ก่อน
• ผู้โจมตีสามารถสร้างไฟล์ใดก็ได้ที่เป็นของ root เพื่อบันทึกข้อมูลจากเทอร์มินัลและนำไปใช้โจมตีต่อ
• ไฟล์ที่มีอยู่แล้วก็สามารถถูกนำไปใช้โจมตีได้ เช่น การแทรกโค้ดลงใน privileged shell script
• Arch Linux, NetBSD 5.0.0 เปราะบางเต็มรูปแบบ ขณะที่ Fedora และบางสภาพแวดล้อมของ Gentoo ได้รับผลกระทบบางส่วน
• แพตช์แก้ไขทำโดยกู้คืนการจัดการไฟล์แบบปลอดภัย และมีรายละเอียดผลกระทบแยกตามดิสทริบิวชัน

3.b) การจี้ TTY ระหว่างการเชื่อมต่อเซสชันหลายผู้ใช้ (CVE-2025-46802)

• ในฟังก์ชัน Attach() เมื่อเปิดใช้แฟลก multiattach จะมีการเปลี่ยน สิทธิ์ของ TTY เป็น 0666 ชั่วคราว
• ระหว่างกระบวนการนี้มี race condition ที่ทำให้ ผู้ใช้รายที่สามสามารถอ่าน/เขียน TTY ดังกล่าวได้
• มีความเสี่ยงทั้งการดักฟังข้อมูลขาเข้า, การแก้ไขข้อมูล, และการขโมยรหัสผ่าน
• ยังมีเส้นทางโค้ดที่ทำให้สิทธิ์ของ TTY ไม่ถูกคืนกลับสู่ค่าเดิม
• แพตช์แก้โดยตัดการทำ chmod 666 ออก; แม้อาจทำให้ use case การเชื่อมต่อซ้ำบางแบบใช้งานไม่ได้ แต่เดิมก็ทำงานไม่ได้อยู่แล้ว

3.c) ช่องโหว่จากสิทธิ์เริ่มต้นของ PTY (CVE-2025-46803)

• ใน 5.0.0 สิทธิ์เริ่มต้นของ PTY ถูกเปลี่ยนจาก 0620 → 0622 (เขียนได้โดยทุกคน)
• ความเสี่ยงด้านความปลอดภัยจึงเพิ่มขึ้น โดยเฉพาะเพราะผู้ใช้ทุกคนสามารถเขียนไปยัง PTY ของผู้อื่นได้
• การเปลี่ยนแปลงนี้ดูเหมือนเกิดจากความผิดพลาด และแพตช์แก้ไขโดยคืนค่าเริ่มต้นที่ปลอดภัยตอนคอมไพล์ (0620)
• Arch Linux, NetBSD เป็นกลุ่มที่ได้รับผลกระทบหลัก

3.d) การรั่วไหลของข้อมูลการมีอยู่ของไฟล์ผ่านข้อความผิดพลาดของซ็อกเก็ต (CVE-2025-46804)

• ใช้ตัวแปรแวดล้อม SCREENDIR และข้อความ Error เพื่อ ตรวจสอบได้ว่ามีไฟล์/ไดเรกทอรีจริงอยู่หรือไม่ด้วยสิทธิ์ root
• เป็นการรั่วไหลของข้อมูลระดับเล็กน้อย แต่มีความเสี่ยงในทุกสภาพแวดล้อมที่ติดตั้งแบบ setuid-root

3.e) race condition แบบ TOCTOU ในการส่งสัญญาณ (CVE-2025-46805)

• จากช่วงเวลาระหว่างฟังก์ชัน CheckPid() และ Kill() ทำให้มีความเสี่ยงที่จะส่งสัญญาณด้วยสิทธิ์ root ไปยัง PID ที่ไม่ใช่เป้าหมาย
• โดยหลักแล้วอนุญาตเฉพาะ SIGCONT, SIGHUP เป็นต้น จึงจำกัดผลกระทบไว้บ้าง แต่ยังอาจก่อให้เกิดการปฏิเสธการให้บริการ (DoS) หรือความเสียหายด้านความถูกต้องเล็กน้อย

3.f) overflow ระหว่างส่งคำสั่งจากการใช้ strncpy() ผิดวิธี

• ใน 5.0.0 เกิด buffer overflow และโปรแกรมแครชจากการใช้ strncpy() อย่างไม่ถูกต้อง
• หากไม่แพตช์อย่างถูกต้อง เมื่อมีการส่งคำสั่งจะเกิดการเขียนทับหน่วยความจำหลัง MAXPATHLEN และนำไปสู่ภาวะบริการใช้งานไม่ได้
• แม้ไม่ใช่ปัญหาด้านความปลอดภัย แต่จำเป็นต้องแก้ไขอย่างรวดเร็วเพื่อความเสถียร

4. ความเสี่ยงเพิ่มเติมที่เกี่ยวข้องกับการทำงานแบบ setuid-root

• พบว่าในโหมดหลายผู้ใช้มี ตรรกะการจัดการ UID ของผู้ใช้หลายรายที่ไม่รัดกุม
• ตรรกะการ drop privilege ในสถานะ setuid-root ยังไม่สมบูรณ์
• ในเซสชันที่ root สร้างขึ้น การลดสิทธิ์อย่างมีประสิทธิภาพไม่เกิดขึ้นจริง ทำให้มีความเสี่ยงโดยรวมสูง

5. คำแนะนำทั่วไปเพื่อเสริมความปลอดภัย

• พบว่าในกระบวนการ refactoring โค้ดขนาดใหญ่ ตรรกะความปลอดภัยเดิมพังลง
• ด้วยธรรมชาติของไบนารีแบบ setuid-root จึงจำเป็นต้องมีชุดทดสอบด้านความปลอดภัย และออกแบบการจัดการไฟล์ซิสเต็ม/ตัวแปรแวดล้อมทั้งหมดอย่างระมัดระวัง
• โดยเฉพาะอย่างยิ่งไม่แนะนำให้รันทั้งโปรแกรมแบบ setuid-root และควรจำกัดฟีเจอร์ multi-user ไว้เฉพาะรูปแบบ opt-in สำหรับกลุ่มที่เชื่อถือได้เท่านั้น
• ตัวแปรแวดล้อม (เช่น PAH) ต้องถูกบังคับให้ระบุได้เฉพาะพาธที่เชื่อถือได้เท่านั้น

6. ปัญหาในกระบวนการประสานการประกาศช่องโหว่

• กระบวนการ ประสานงานกับ upstream ดำเนินไปอย่างไม่มีประสิทธิภาพ ทำให้การพัฒนาแพตช์และการเปิดเผยข้อมูลล่าช้า
• เนื่องจาก upstream ขาดความเข้าใจโค้ดและศักยภาพที่เพียงพอ จึงตอบสนองอย่างใกล้ชิดได้ยาก
• สุดท้ายฝ่ายดิสทริบิวชันเป็นผู้ขับเคลื่อนการพัฒนาแพตช์ และมีการเผยแพร่รายงานตามกำหนดการที่ประสานกันแล้ว
• ยังพบด้วยว่าโครงการ Screen เองมี ข้อจำกัดด้านศักยภาพในการดูแลและบำรุงรักษา

7. เมทริกซ์ผลกระทบ

• Arch Linux (5.0.0, setuid-root): ได้รับผลกระทบจาก 3.a, 3.b, 3.c, 3.d, 3.e, 3.f ทั้งหมด
• Debian/Ubuntu และดิสทริบิวชันอีกหลายรายการ: 3.b (ได้รับผลกระทบบางส่วน)
• Fedora 42 (5.0.0, setgid-screen): 3.b (ได้รับผลกระทบบางส่วน), 3.f
• Gentoo (4.9.1, setgid-utmp): 3.b (ได้รับผลกระทบบางส่วน), และหากเป็น unstable ebuild + USE flag multiuser จะได้รับผลเหมือน 5.0.0
• 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 (ได้รับผลกระทบบางส่วน)
• openSUSE TW: 3.b (ได้รับผลกระทบบางส่วน)

8. กำหนดการ

• 2024-07-01: ได้รับคำขอรีวิวโค้ดจาก upstream
• 2025-01-08: เริ่มการรีวิว
• 2025-02-07: รายงานช่องโหว่ให้ upstream แบบไม่เปิดเผยต่อสาธารณะ พร้อมขอเปิดเผยแบบประสานงาน
• 2025-02~04: มีการหารือเรื่องแพตช์ และกำหนดการถูกปรับใหม่จากประเด็นช่วง embargo
• 2025-05-12: เผยแพร่รายงานฉบับนี้และประกาศอย่างเป็นทางการ

9. ลิงก์อ้างอิง

• GNU Savannah [หน้าของโครงการ Screen]
• openSUSE Bugzilla, แพตช์ที่เกี่ยวข้อง, CVE อ้างอิง, รายงานบั๊ก และลิงก์เอกสาร

[GN⁺]

ความคิดเห็นจาก Hacker News

• Screen มีโหมด multi-user ที่อนุญาตให้หลายผู้ใช้เข้าถึงเซสชันเดียวกันได้ คิดว่าฟีเจอร์นี้นี่เองที่ทำให้เครื่องมืออย่าง tmate เป็นไปได้ เลยสงสัยว่า tmux มีช่องโหว่แบบเดียวกันหรือไม่
  • tmux ใช้ Unix domain socket ไม่เข้าใจว่าทำไม screen ถึงใช้วิธี setuid ดูเหมือนไม่จำเป็นต้องใช้สิทธิ์ root ตามที่อธิบายในบทความต้นทาง ปัจจุบันดูเหมือนนักพัฒนา screen จะยังไม่เข้าใจโค้ดเบสทั้งหมด เลยเลือกแนวทาง setuid-root เพราะทำให้ทำฟีเจอร์ได้ง่ายกว่า
  • ฟีเจอร์นี้ยอดเยี่ยมมาก ในเซสชันฝึกอบรม ฉันให้บัญชีล็อกอินของตัวเองบนแล็ปท็อปแก่นักเรียนแต่ละคน แล้วจำกัด ssh shell ไว้ที่ screen -x <หน้าต่างของผู้ใช้ที่กำหนด> เพื่อให้นักเรียนใช้ได้เฉพาะหน้าต่างที่ได้รับอนุญาตใน ACL ของ screen นั้น ฉันใช้โปรเจ็กเตอร์เปิดดูหน้าจอของนักเรียนทีละคนให้ทุกคนเห็น แต่ก็ไม่น่าแปลกใจที่มันเต็มไปด้วยช่องโหว่ความปลอดภัย
  • เคยมีประสบการณ์ใช้คำสั่ง screen -x
• บน Debian นั้น GNU screen ไม่ได้ถูกติดตั้งแบบ setuid root
  • แพ็กเกจ Debian Stable (bookworm) เก่าเกินไปจึงไม่ได้รับผลกระทบจากช่องโหว่ใน 5.0.0 เมื่อก่อนฉันไม่ชอบที่ Debian อัปเดตเวอร์ชันซอฟต์แวร์ช้ามาก แต่ตอนนี้ใช้ซอร์สแพ็กเกจแยกเฉพาะกับแอปที่จำเป็นบางตัวเพื่อใช้เวอร์ชันใหม่ ส่วนตัวอื่น ๆ ก็ยังใช้เวอร์ชันเก่าได้ดี
  • Gentoo ก็เช่นกัน แต่ใน Gentoo มีการตั้งค่า SETGID ให้กับกลุ่ม utmp ซึ่งฉันก็ไม่ค่อยแน่ใจว่าหมายความว่าอย่างไร
  • บน Slackware 15 นั้น screen ไม่มี suid
  • บน Fedora ดูเหมือนจะติดตั้งแบบ setuid
• แนะนำเวอร์ชันที่เรนเดอร์แล้วของบทความบล็อก: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• เอกสารเกี่ยวกับฟังก์ชันบันทึกลงไฟล์ล็อกของ GNU Screen มีน้อยมาก เลยส่งอีเมลหาผู้เขียนบทความ คิดว่า GNU ควรมีระบบติดตาม issue ที่ดีกว่านี้ เอกสารที่เกี่ยวข้อง: http://www.zoobab.com/screenrc
  • เคยมี Q&A กับผู้เขียน Tmux ด้วย และมีการบ่นเรื่องเอกสารไม่เพียงพอมาตั้งแต่ 16 ปีก่อนแล้ว เอกสารที่เกี่ยวข้อง: https://undeadly.org/cgi?action=article&sid=20090712190402
• observed behaviour นี้มีอยู่ใน Screen มาตั้งแต่ปี 2005 เป็น anti-pattern ที่ถูกเครื่องมืออย่าง rkhunter คอยครอบไว้มาเป็นเวลานาน และฉันมั่นใจว่าในยุค 90 screen ก็เป็น setuid root อยู่แล้ว
• น่าแปลกใจที่ upstream (ทีมพัฒนาอย่างเป็นทางการ) เข้ามาเกี่ยวข้องครั้งนี้ เมื่อราว 5 ปีก่อนฉันเสียใจที่ดูเหมือนการพัฒนา GNU screen จะหยุดไปโดยสิ้นเชิง ไม่แน่ใจว่าตอนนี้ยังเป็นแบบนั้นอยู่หรือไม่ และก็สงสัยว่ามีฟีเจอร์เพิ่มหน้าต่างใหม่ให้ screen โดยไม่ต้อง attach หน้าจอได้ไหม
  • upstream เป็นฝ่ายขอให้ทีม SUSE ช่วยตรวจสอบ ดูเหมือนจะขาดกำลังคนและตอนนี้ไม่ได้รับการดูแลรักษามากนัก ถ้าเป็นอย่างนั้นก็น่าเสียดาย ถึงจะมีทางเลือกอย่าง tmux แต่หลายคนก็ใช้ Screen มานานแล้ว จึงน่าเสียดายกับอาการเก่าลงของเครื่องมือ
  • สิ่งเดียวที่ upstream มีส่วนเกี่ยวข้องคือการแจกจ่ายแบบ setuid-root ซึ่งทำให้เฉพาะดิสโทรที่ตั้งค่าแบบนี้เท่านั้นที่มีช่องโหว่ ที่เหลือไม่กระทบ ถ้าแพตช์ทางการออกช้า ดิสโทรก็มักจะแพตช์กันเอง
  • ฉันไม่คิดว่าการที่เครื่องมือ GNU หยุดพัฒนาไปแล้ว (ยกเว้นการแก้บั๊ก) จะเป็นเรื่องไม่ดีเสมอไป มันอาจเป็นสัญญาณว่าฟีเจอร์ต่าง ๆ สมบูรณ์เพียงพอแล้ว
  • สื่อสารกับ upstream ได้ยาก จึงไม่มีข้อมูลละเอียดเกี่ยวกับการแก้บั๊กหรือรีลีส ขอให้มีการตรวจสอบด้านความปลอดภัยแล้ว แต่ดูเหมือนจะติดต่อกันได้ยาก
  • โอเพนซอร์สมีปัญหาเรื่องแรงเฉื่อย เพราะแม้ซอฟต์แวร์หนึ่งจะจบลงและมีตัวแทนใหม่ ก็ยังไม่มีแรงจูงใจมากพอให้คนย้ายทันที ในทางกลับกันก็มีกรณีซื้อแค่เครื่องหมายการค้าแล้วเปลี่ยนเป็นคนละอย่างไปเลยด้วย (เช่น Audacity) ซึ่งก็ไม่มีทางออกที่ดีนัก
• ลิงก์เวอร์ชันที่เรนเดอร์แล้ว: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• สงสัยว่ามีนักพัฒนากี่คนที่ได้ลองใช้เครื่องมือโอเพนซอร์สยอดนิยมทั้งหมดด้วยตัวเองจริง ๆ และในสาขาที่ใช้เครื่องมือเหล่านั้นมีเม็ดเงินหมุนเวียนอยู่มากแค่ไหน
• จำได้ว่า tmux ถูกรวมมาเป็นค่าเริ่มต้นใน OpenBSD ตั้งแต่ 4.6 และผ่านการ audit มาแล้ว เป็นทางเลือกที่ดีสำหรับคนที่ใส่ใจความปลอดภัยมากกว่า
  • พอเห็นการพูดถึง screen ก็ทำให้นึกถึงตอนที่เคยย้ายไปใช้ tmux แล้วสับสนเพราะเผลอไม่ใช้ screen อยู่พักหนึ่ง
• น่าสนใจที่มีการพูดถึง screen กับ setuid ครั้งหนึ่งฉันเคยแก้ปัญหาแปลก ๆ โดยให้ chmod u+s กับ screen ความรู้สึกตอนต้องทำแบบนั้นมันแปลกมาก แต่ภายหลังถึงรู้ว่า screen มีฟีเจอร์ที่พึ่งพา setuid และบางระบบก็แจกจ่ายมาแบบนั้นเป็นค่าเริ่มต้น และเมื่อให้ u+s แล้ว screen ก็ไปอ่าน ~/.screenrc ของ root แทนของฉันเอง (ก็ยอมรับเป็นวิธีแก้ชั่วคราว) คิดว่าในแต่ละ build ของ screen อาจรองรับ setuid ไม่เหมือนกัน
  • setuid เดิมทีก็ทำงานแบบนั้นอยู่แล้ว การตั้ง special bit ให้ไบนารีหมายถึงให้รันด้วยผู้ใช้ที่กำหนดไว้เสมอ