ssh-keysign-pwn - PoC ของช่องโหว่ 0-day บน Linux ที่ทำให้ผู้ใช้ไม่มีสิทธิ์อ่านไฟล์ที่ root เป็นเจ้าของได้

 (github.com/0xdeadbeefnetwork)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ssh-keysign-pwn เป็น PoC ของช่องโหว่บน Linux ที่ทำให้ผู้ใช้ไม่มีสิทธิ์สามารถอ่านไฟล์ที่ root เป็นเจ้าของได้ โดยระบุว่าเคอร์เนลก่อน 31e62c2ebbfd ได้รับผลกระทบ
  • บั๊กหลักคือ __ptrace_may_access() จะข้ามการตรวจสอบ dumpable เมื่อ task->mm == NULL และ do_exit() เรียก exit_mm() ก่อน exit_files() ทำให้เกิดช่วงเวลาที่ file descriptor ยังเปิดค้างอยู่
  • ในช่วงเวลานี้ หาก uid ของผู้เรียกตรงกับโปรเซสเป้าหมาย pidfd_getfd(2) จะสำเร็จ ทำให้สามารถดึง file descriptor ที่เปิดอยู่ของโปรเซสที่กำลังปิดตัวลงมาได้
  • sshkeysign_pwn ดึง /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key โดยอาศัยลำดับการทำงานที่ ssh-keysign.c เปิดคีย์ที่มีสิทธิ์ 0600 แล้วจบการทำงานด้วย EnableSSHKeysign=no ก่อน permanently_set_uid() ส่งผลให้ fd ที่เปิดอยู่ยังค้างไว้
  • chage_pwn ดึง /etc/shadow โดยอาศัย race ตอนจบการทำงานในลำดับที่ chage -l <user> เรียก spw_open(O_RDONLY) แล้วลดสิทธิ์ลงทั้งหมดด้วย setreuid(ruid, ruid)
  • วิธีรันคือ make จากนั้นใช้ ./sshkeysign_pwn เพื่อดึง host key และใช้ ./chage_pwn root เพื่อพิมพ์เนื้อหา /etc/shadow ออกทาง standard output โดยระบุว่ามักสำเร็จภายใน 100~2000 ครั้งของการสปอน
  • สภาพแวดล้อมที่ยืนยันแล้วคือ Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch และ CentOS 9
  • สำหรับ PoC เป้าหมายแบบควบคุมได้ vuln_target.c จะเปิด /etc/shadow แล้วลดสิทธิ์ลง ส่วน exploit_vuln_target.c แสดงให้เห็นทั้ง EPERM ระหว่างโปรเซสยังมีชีวิตอยู่ และการขโมย fd หลัง SIGKILL
  • ระบุว่า Qualys เป็นผู้รายงานช่องโหว่, Linus แก้ไขเมื่อ 2026-05-14 และ Jann Horn เคยชี้ประเด็นรูปแบบการ ขโมย FD ไว้ตั้งแต่เดือนตุลาคม 2020
  • README ระบุรายการ NVD ที่ https://nvd.nist.gov/vuln/detail/CVE-2026-46333

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs

  • แค่ ปิด ptrace อย่างเดียวไม่เพียงพอ แม้จะเข้าใจผิดได้ง่ายจากข้อความคอมมิตและชื่อฟังก์ชัน แต่ ptrace_may_access ถูกเรียกใช้จากหลายเส้นทาง และ PoC นี้ก็ไม่ได้ใช้ ptrace จริง ๆ
    ดูเหมือนจะไม่มีมาตรการบรรเทาที่ดีนัก ตอนนี้จึงน่าจะมีแค่ 1) เอาบิต execute ออกจาก /usr/lib64/misc/ssh-keysign ทั้งหมดเพื่อรับมือแบบเฉพาะกับ PoC นี้อย่างอ่อน ๆ หรือ 2) ใช้ eBPF หรือ systemtap อะไรทำนองนั้นเพื่อ บล็อก pidfd_getfd อย่างแรกนี่คงพิจารณาเฉพาะตอนที่ยังแพตช์เคอร์เนลหรือปิดเครื่องไม่ได้และต้องไปนอนเดี๋ยวนั้น
    ยังไม่ได้ตรวจ PoC และก็เหมือนทุกครั้ง ควรระวังเสมอเมื่อรัน PoC สุ่มที่โหลดมาจากอินเทอร์เน็ต
    คำแนะนำของ Qualys ยังไม่ถูกเผยแพร่ และก่อนหน้านี้ก็เคยบอกว่าจะยุติการเผยแพร่ผ่าน linux-distros ด้วยความไม่เต็มใจอย่างยิ่งเพราะนโยบายความปลอดภัยของ Linux kernel เมื่อ LLM สามารถสร้าง PoC ได้อย่างรวดเร็วจากคอมมิตแก้ไขที่ดูน่าสงสัย สถานการณ์ก็รุนแรงขึ้น และถ้าเป็นเมื่อก่อนคงยังรอได้อีกไม่กี่วัน
    Qualys เป็นทีมที่ยอดเยี่ยมจริง ๆ แต่ก็น่าเสียดายที่ครั้งนี้พวกเขาไม่ได้มีจังหวะเหมาะ ๆ ในการประกาศเรื่องนี้ด้วยตัวเอง พอเผยแพร่ออกมาเมื่อไร ก็คงเป็นคำแนะนำที่ยอดเยี่ยมแน่นอน
    openssh เป็นเพียงเป้าหมายที่สะดวกสำหรับการโจมตีนี้ ไม่ได้เป็นฝ่ายผิด และไบนารี setuid ตัวอื่นก็น่าจะถูกเลือกเป็นเป้าหมายได้เช่นกัน

    • ตามอัปเดตของ Qualys ถ้าตั้งค่า /proc/sys/kernel/yama/ptrace_scope เป็น 2 (admin-only attach) หรือ 3 (no attach) จะป้องกัน exploit ที่รู้จักทั้งหมดได้ แต่ในทางทฤษฎีก็อาจยังมีวิธีโจมตีแบบอื่นได้
    • เพื่อบรรเทาแบบเร่งด่วน มีการให้ LLM ชื่อ Opus เขียน systemtap script สำหรับบล็อก pidfd_getfd และผลลัพธ์อยู่ที่นี่ ต้องรันด้วย stap -g block_pidfd_getfd.stp และเช่นเดียวกับทุกอย่างที่ได้มาจากอินเทอร์เน็ต ควรตรวจสคริปต์ก่อนรันเสมอ
    • มีลิงก์ไปประกาศบน linux-distros ไหม? หาไม่เจอ

  • อยากให้เคอร์เนลเลิก เปิดเผย 0-day เอง ด้วยการคอมมิตแพตช์ลงเมนบรันช์แบบสาธารณะ คอมมิต ถึงกับเขียนว่า “Reported-by: Qualys” เลย จึงชัดเจนว่าเป็นการแก้ช่องโหว่ความปลอดภัย

    • สัปดาห์ก่อนมีการถกเถียงใหญ่เกี่ยวกับเรื่องนี้
      Greg K-H เขียนว่าทีมความปลอดภัยของเคอร์เนลไม่สามารถเลือกได้ว่าจะเปิดเผยแพตช์ความปลอดภัยล่วงหน้าให้ใครบ้าง ดังนั้นผลลัพธ์คือไม่มีใครได้รับการเปิดเผยล่วงหน้าเลย
    • ถ้าอย่างนั้นควรทำอย่างไรแทน?

  • นี่ไม่ใช่ปัญหา ssh แต่เป็น ปัญหาของ Linux ชื่อก็ควรสื่อแบบนั้น

    • เห็นด้วยว่าชื่อทำให้เข้าใจผิด แต่ก็ยังนึกไม่ออกว่าจะตั้งชื่ออย่างไรดี ยังแก้ได้อยู่ ถ้ามีข้อเสนอแนะก็ดีเลย
    • จริง แต่ในอีกด้านหนึ่ง ถ้า ssh-keysign ตรวจ EnableSSHKeysign=yes ก่อนเปิด host key ส่วนตัว ระบบที่ปิดออปชันนี้ไว้ตามค่าเริ่มต้นก็คงไม่เสี่ยงต่อ การขโมย host key จุดที่น่าแปลกใจคือ ssh-keysign ไม่ได้เช็กออปชันนี้เป็นอย่างแรก

  • PoC สั้นจนน่าพอใจ และเครื่องของฉันก็มีช่องโหว่จริง
    ดูเหมือนว่ามันทำให้เข้าถึง file descriptor ที่โปรแกรม setuid เปิดไว้ได้ในบางเงื่อนไข ฉันไม่เห็นเหตุผลว่าทำไมมันจะจำกัดแค่อ่านอย่างเดียว และน่าจะดัดเป็น local privilege escalation (LPE) ที่ไม่ต้องไปแคร็กแฮชได้
    อย่างน้อย PoC นี้ทำให้ใช้ไม่ได้ด้วย chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage อาจต้องเปลี่ยนพาธของ ssh-keysign และดูman pageประกอบด้วย แต่ก็ไม่ได้แก้ปัญหาหลัก และน่าจะมีทางเลี่ยงได้ เท่าที่รู้ก็ยังไม่มีมาตรการบรรเทาอื่น
    ปัญหานี้ถูกแก้ใน ptrace: slightly saner 'get_dumpable()' logic และนั่นเองที่ทำให้มันถูกเปิดเผยไปแล้ว เรื่องเพิ่งเกิดขึ้นเมื่อ 10 ชั่วโมงก่อนเท่านั้น
    ยังมีประกาศเปิดเผยของ Qualys ที่ส่งไปยัง oss-security ด้วย โดยบอกว่ายังไม่เผยแพร่คำแนะนำอย่างเป็นทางการเพื่อให้ดิสโทรและผู้ใช้มีเวลาแพตช์ก่อน ดูน่าจะเป็นเนื้อหาที่น่าสนใจมาก และระหว่างนี้ให้อ่านคำอธิบายของ Brad Spengler จาก grsecurityไปก่อน ทวีตนี้ดูเหมือนจะเป็นตัวจุดชนวนให้เกิดการพัฒนา PoC ครั้งนี้

    • ลองรัน PoC แล้ว แต่ยังชนะ race ไม่ได้ อย่างไรก็ตาม คู่ exploit_vuln_target/vuln_target ทำงานได้ดี ซึ่งไม่ค่อยดีเท่าไร

  • ในทางปฏิบัติดูเหมือนว่าจะกระทบระบบที่มีผู้ใช้ บัญชีไม่มีสิทธิพิเศษ อยู่แล้ว นั่นคือ ถ้าไม่มีล็อกอินที่ใช้งานได้จริง ก็คงยังไม่ใช่ว่าจะใช้สิ่งนี้ทำ remote code execution บนเซิร์ฟเวอร์ SSH ที่เปิดออกอินเทอร์เน็ตได้ตรง ๆ ใช่ไหม?

    • ใช่ แต่จะเป็นข้อยกเว้นถ้าสามารถได้ RCE จากบริการอื่นก่อน เช่น nginx remote code execution ที่เพิ่งมีโพสต์เมื่อไม่กี่วันก่อน