Copy Fail – CVE-2026-31431

 (copy.fail)
3 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้ใช้ภายในเครื่องที่ไม่มีสิทธิพิเศษ สามารถเชื่อม authencesn, AF_ALG, splice() เพื่อสร้างการ เขียน 4 ไบต์ลง page cache ของไฟล์ที่อ่านได้ และยกระดับสิทธิ์ไปจนถึง root ได้
  • ทำงานได้เหมือนกันบน Linux หลายดิสทริบิวชันด้วย สคริปต์ Python ขนาด 732 ไบต์ เพียงไฟล์เดียว โดยไม่ต้องพึ่ง offset เฉพาะเคอร์เนลหรือ race condition และใช้ exploit เดียวกันเพื่อให้ได้ root shell
  • ขอบเขตผลกระทบครอบคลุม ดิสทริบิวชัน Linux หลักเกือบทั้งหมด ที่ยังไม่แพตช์ และเนื่องจาก AF_ALG เปิดใช้งานในค่าตั้งต้น จึงเปิดช่องมาตั้งแต่ปี 2017 จนถึงช่วงที่ออกแพตช์
  • ในโฮสต์แบบ multi-tenant, Kubernetes / คลัสเตอร์คอนเทนเนอร์, CI runner และ Cloud SaaS ที่รันโค้ดผู้ใช้ บัญชีธรรมดาหรือ pod เดียวอาจนำไปสู่สิทธิ์ root บนโฮสต์ได้ จึงควรเร่งแพตช์ก่อน
  • วิธีรับมืออันดับแรกคือ แพตช์เคอร์เนล ที่มี mainline commit a664bf3d603d และก่อนจะแพตช์ควรปิด algif_aead พร้อม บล็อก AF_ALG สำหรับ workload ที่ไม่น่าเชื่อถือ

ภาพรวมช่องโหว่

  • ความผิดพลาดเชิงตรรกะแบบ เส้นตรงเพียงจุดเดียว เมื่อเชื่อมกับ authencesn, AF_ALG, splice() สามารถนำไปสู่การ เขียน 4 ไบต์ลง page cache และทำให้เกิดการยกระดับสิทธิ์ภายในเครื่องได้
  • ใช้งานได้เหมือนกันกับ Linux ดิสทริบิวชันจำนวนมากที่ออกตั้งแต่ปี 2017 เป็นต้นมา ด้วย สคริปต์ Python ขนาด 732 ไบต์ เพียงไฟล์เดียว โดยไม่ต้องมี offset เฉพาะเคอร์เนลหรือ race window
  • exploit binary เดียวกันสามารถใช้เพื่อให้ได้ root shell บนหลายดิสทริบิวชันโดยไม่ต้องแก้ไข
  • ต้องการเพียงบัญชี local ที่ไม่มีสิทธิพิเศษเท่านั้น ไม่ต้องเข้าถึงเครือข่าย ไม่ต้องมีความสามารถด้าน kernel debugging และไม่ต้องมี primitive อื่นติดตั้งไว้ล่วงหน้า

ขอบเขตผลกระทบ

  • ดิสทริบิวชัน Linux หลักเกือบทั้งหมด ที่ใช้เคอร์เนลซึ่งยังไม่แพตช์อยู่ในขอบเขตผลกระทบ
  • เพราะ AF_ALG ของ kernel crypto API ถูกเปิดไว้โดยปริยายในแทบทุกดิสทริบิวชันกระแสหลัก ระบบจึงเปิดรับช่องโหว่นี้โดยตรงตั้งแต่ปี 2017 จนถึงเวลาที่มีแพตช์
  • ดิสทริบิวชันที่ตรวจสอบโดยตรงแล้วได้แก่ Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3 และ SUSE 16
  • Debian, Arch, Fedora, Rocky, Alma, Oracle รวมถึงสาย embedded ก็ได้รับผลกระทบเช่นกันหากใช้เคอร์เนลที่ได้รับผลกระทบ

สภาพแวดล้อมที่ควรเร่งแพตช์ก่อน

  • บน โฮสต์ Linux แบบ multi-tenant ผู้ใช้หลายรายแชร์เคอร์เนลเดียวกัน ทำให้บัญชีผู้ใช้ธรรมดาสามารถกลายเป็น root ได้โดยตรง
  • ใน Kubernetes / คลัสเตอร์คอนเทนเนอร์ page cache ถูกแชร์ทั้งโฮสต์ ดังนั้น pod เดียวอาจยึด node และข้ามขอบเขตผู้เช่าได้
  • ใน CI runner และ build farm โค้ดจาก PR ที่ไม่น่าเชื่อถือซึ่งรันด้วยสิทธิ์ผู้ใช้ธรรมดา อาจยกระดับเป็น root บน runner ได้
  • ใน Cloud SaaS ที่รันโค้ดผู้ใช้ คอนเทนเนอร์หรือสคริปต์ที่ผู้เช่าอัปโหลดอาจนำไปสู่ root บนโฮสต์ได้
  • เซิร์ฟเวอร์แบบ single-tenant มีลักษณะเป็น LPE ภายในเป็นหลัก และอาจเชื่อมกับเว็บ RCE หรือ credential ที่ถูกขโมยมาได้
  • โน้ตบุ๊กและเวิร์กสเตชันผู้ใช้คนเดียวมีความเร่งด่วนน้อยกว่า แต่การรันโค้ดในเครื่องก็ยังอาจนำไปสู่การยกระดับเป็น root ได้

PoC ที่เผยแพร่และวิธีใช้งาน

  • มีการเผยแพร่ PoC เพื่อให้ฝั่งป้องกันใช้ตรวจสอบระบบและยืนยันแพตช์จากผู้จำหน่ายได้
  • copy_fail_exp.py ใช้เพียงไลบรารีมาตรฐานของ Python 3.10+ ได้แก่ os, socket, zlib
  • เป้าหมายตั้งต้นคือ /usr/bin/su และสามารถส่ง setuid binary อื่นผ่าน argv[1] ได้
  • มันแก้ไข setuid binary ภายใน page cache และแม้การเปลี่ยนแปลงจะไม่คงอยู่หลังรีบูต แต่ root shell ที่ได้มาสามารถใช้งานได้จริง
  • Issue tracker

วิธีบรรเทา

  • สิ่งสำคัญอันดับแรกคือ แพตช์เคอร์เนล โดยต้องอัปเดตไปใช้เคอร์เนลดิสทริบิวชันที่รวม mainline commit a664bf3d603d แล้ว
  • แพตช์นี้ย้อนการเพิ่มประสิทธิภาพแบบ in-place ของ algif_aead ที่ถูกนำเข้ามาตั้งแต่ปี 2017 เพื่อไม่ให้หน้า page cache เข้าไปอยู่ใน writable destination scatterlist
  • ก่อนมีแพตช์ แนะนำให้ ปิดโมดูล algif_aead
    • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
    • rmmod algif_aead 2>/dev/null || true
  • ในคอนเทนเนอร์ sandbox และ CI ที่รัน workload ที่ไม่น่าเชื่อถือ ควร บล็อกการสร้าง socket AF_ALG ด้วย seccomp ไม่ว่าจะมีแพตช์แล้วหรือไม่ก็ตาม

ผลกระทบเมื่อปิดใช้งาน

  • สำหรับระบบส่วนใหญ่ แทบไม่มีผลกระทบที่วัดได้
  • dm-crypt / LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS แบบ build ปกติ, SSH และ kernel keyring crypto ไม่ได้รับผลกระทบ
    • สิ่งเหล่านี้ใช้ kernel crypto API โดยตรงและไม่ได้ผ่านเส้นทาง AF_ALG
  • หากเปิดใช้เอนจิน afalg ใน OpenSSL แบบชัดเจน, ใช้เส้นทาง embedded crypto offloading บางแบบ หรือมีแอปพลิเคชันที่ bind socket aead/skcipher/hash โดยตรง ก็อาจได้รับผลกระทบ
    • ตรวจสอบได้ด้วย lsof | grep AF_ALG หรือ ss -xa
  • การปิด AF_ALG จะไม่ทำให้เป้าหมายที่เดิมไม่ได้เรียกใช้งานมันช้าลง และเป้าหมายที่ใช้งานอยู่จะย้อนกลับไปใช้ไลบรารีเข้ารหัสใน userspace ตามปกติ

จุดที่ต่างจาก Linux LPE ทั่วไป

  • ต่างจาก Linux LPE ทั่วไปตรงที่ ไม่มี race condition และไม่ต้องใช้ offset แยกตามดิสทริบิวชัน
  • ยังระบุว่ามีความน่าเชื่อถือ ยิงครั้งเดียวสำเร็จ 100% และครอบคลุมช่วงเวลายาวตั้งแต่ปี 2017 ถึง 2026 ไม่ใช่แค่ช่วงเวอร์ชันเคอร์เนลแคบ ๆ
  • ด้วยขนาดเพียง 732 ไบต์ และใช้แค่ไลบรารีมาตรฐานของ Python จึงไม่ต้องมี payload ที่คอมไพล์แล้วหรือ dependency เพิ่มเติม
  • เส้นทางการเขียน ข้าม VFS และ page ที่ถูกทำให้เสียหายจะไม่ถูกทำเครื่องหมาย dirty จึงไม่มีการเขียนอะไรลงดิสก์
  • เนื่องจาก page cache ถูกแชร์ทั้งโฮสต์ มันจึงทำงานได้มากกว่าแค่ LPE ธรรมดา แต่ยังเป็น primitive สำหรับ container escape ได้ด้วย

หลักการทำงานและลักษณะการตรวจจับ

  • ผู้ใช้ภายในเครื่องที่ไม่มีสิทธิพิเศษสามารถเขียน 4 ไบต์ที่ควบคุมได้ลงใน page cache ของไฟล์ที่อ่านได้ บนระบบ Linux และนำไปใช้เพื่อให้ได้สิทธิ์ root
  • เป้าหมายคือ page cache ในหน่วยความจำ ไม่ใช่ไฟล์จริงบนดิสก์ และถ้าแก้สำเนาในแคชของ /usr/bin/su จากมุมมองของ execve ก็เทียบเท่ากับการเปลี่ยนตัวไบนารีเอง
  • เพราะไม่มีการเปลี่ยนแปลงบนดิสก์ inotify จึงไม่แจ้งเตือน และหลังรีบูตหรือเมื่อ cache ถูกขับออก ไฟล์ต้นฉบับจะถูกโหลดกลับมาใหม่
  • เครื่องมือแฮชทั่วไปอย่าง sha256sum, AIDE, Tripwire จะอ่าน page cache ผ่าน read() ดังนั้น ตราบใดที่ความเสียหายยังคงอยู่ในแคช ค่าแฮชอาจไม่ตรงกับค่าอ้างอิง
  • เมื่อ cache ถูกขับออกหรือรีบูต ค่าแฮชจะกลับมาตรงกับต้นฉบับอีกครั้ง และใน forensic image ของดิสก์ก็จะเหลือเพียงไฟล์ที่ยังไม่ถูกแก้ไข
  • ใน IMA appraisal enforcing mode หากเปิด every-read measurement ก็สามารถตรวจจับได้ที่จุด execve ก่อนที่ไบนารีที่เสียหายจะถูกรัน

ความต่างจากช่องโหว่อื่น

  • อยู่ในตระกูลเดียวกับ Dirty Pipe ตรงที่ userspace ที่ไม่มีสิทธิพิเศษสามารถทำให้ page cache เสียหายและเขียนลง setuid binary เพื่อเอา root ได้โดยไม่เปลี่ยนข้อมูลบนดิสก์
  • แต่กลไกต่างกัน โดย Dirty Pipe ใช้ประโยชน์จาก pipe buffer flags ส่วน Copy Fail ใช้ประโยชน์จาก AEAD scratch write ที่ข้ามขอบเขต chained scatterlist
  • Dirty Pipe ต้องอาศัยเคอร์เนล 5.8 ขึ้นไปที่มีแพตช์บางตัวเข้าไปแล้ว แต่ Copy Fail ครอบคลุมช่วงตั้งแต่ปี 2017 ถึง 2026
  • ต่างจาก Dirty Cow ตรงที่ไม่ต้องชนะ COW race แบบ TOCTOU ไม่ต้องลองหลายครั้ง และไม่ทำให้ระบบไม่เสถียร

รายละเอียดเพิ่มเติม

  • /usr/bin/su ไม่ใช่ข้อบังคับ หากเป็น setuid-root binary ที่ผู้ใช้อ่านได้ ก็ใช้กับ passwd, chsh, chfn, mount, sudo, pkexec ได้เช่นกัน
  • ไม่ใช่ช่องโหว่ระยะไกล และต้องมี การรันโค้ดในเครื่องด้วยสิทธิ์ผู้ใช้ทั่วไป ก่อน
  • หากเว็บ RCE ตกมาที่บัญชีบริการที่ไม่มีสิทธิพิเศษ หรือเชื่อมกับ SSH foothold, PR อันตรายบน CI runner ก็สามารถนำไปสู่ root ได้
  • แพตช์จะย้อนการเพิ่มประสิทธิภาพแบบ in-place ของ algif_aead ทำให้ req->src และ req->dst กลับไปเป็น scatterlist ที่แยกกัน
  • หน้า page cache จะคงอยู่เฉพาะใน source แบบอ่านอย่างเดียว ส่วนปลายทางที่ crypto เขียนได้จะเหลือเพียง user buffer

กำหนดการเปิดเผยและข้อมูลติดตาม

  • 2026-03-23 มีการรายงานไปยังทีมความปลอดภัยของ Linux kernel
  • 2026-03-24 มีการยืนยันเบื้องต้น
  • 2026-03-25 มีการเสนอและทบทวนแพตช์
  • 2026-04-01 แพตช์ถูก commit เข้า mainline
  • 2026-04-22 มีการกำหนด CVE-2026-31431
  • 2026-04-29 เปิดเผยที่ https://copy.fail/
  • บทวิเคราะห์ทางเทคนิคจาก Xint blog
    • มี root cause, แผนภาพ scatterlist, ลำดับเหตุการณ์ปี 2011→2015→2017 และ walkthrough ของ exploit
    • Part 2 ที่จะพูดถึงการหนีออกจากคอนเทนเนอร์ใน Kubernetes จะเผยแพร่ภายหลัง

ข้อมูลเกี่ยวกับ Xint Code

  • ค้นพบด้วยวิธี AI-assisted โดยจุดตั้งต้นคือการวิจัยของมนุษย์ที่ตั้งข้อสังเกตว่า splice() ส่งหน้า page cache เข้าไปยัง crypto subsystem และแหล่งที่มาของ page ใน scatterlist อาจเป็นคลาสบั๊กที่ยังถูกสำรวจไม่มาก
  • จากนั้น Xint Code ได้ขยายการตรวจสอบไปยัง subsystem crypto/ ทั้งหมดของ Linux ในระดับเวลาประมาณ 1 ชั่วโมง และรายการที่ ร้ายแรงที่สุด จากผลลัพธ์นั้นก็คือ Copy Fail
  • Xint Code
    • Xint blog write-up
    • จากการสแกนเดียวกันยังพบบั๊กความเสี่ยงสูงอื่น ๆ อีก ซึ่งยังอยู่ระหว่าง coordinated disclosure

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

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

 
GN⁺ 5 시간 전
ความเห็นจาก Hacker News

  • ในมุมของคนที่ทำงานกับโค้ด crypto ของเคอร์เนล Linux ช่องโหว่ AF_ALG exploit ที่โผล่มาเป็นระยะนี่ชวนหงุดหงิดมาก
    AF_ALG ถูกใส่เข้ามาในเคอร์เนลตั้งนานแล้วโดยแทบไม่ได้รับการรีวิวมากพอ โครงสร้างก็ซับซ้อนเกินไป แถมยังเปิดพื้นผิวการโจมตีขนาดใหญ่ให้กับโปรแกรม userspace ที่ไม่มีสิทธิพิเศษ
    ยิ่งไปกว่านั้นมันแทบไม่จำเป็นเลย เพราะฝั่ง userspace ก็มีโค้ดเข้ารหัสของตัวเองอยู่แล้ว และโค้ด crypto ในเคอร์เนลเดิมทีก็มีไว้สำหรับการใช้งานภายในเคอร์เนลอย่าง dm-crypt
    แม้แต่ authencesn ใน exploit ครั้งนี้เอง ก็เป็นรายละเอียดการติดตั้งใช้งานภายในของ IPsec เป็นหลัก การเอาสิ่งนี้มาเปิดเป็น API เข้ารหัส/ถอดรหัสทั่วไปสำหรับ userspace ตั้งแต่แรกจึงดูเป็นการตัดสินใจที่ผิด
    ถ้าคุณเป็นคนดูแลการตั้งค่าเคอร์เนล Linux ขอแนะนำอย่างยิ่งให้ปิดทุกตัวเลือก CONFIG_CRYPTO_USER_API_*
    ถ้าทำแค่นั้น ไม่ใช่แค่บั๊กครั้งนี้ แต่บั๊ก AF_ALG จำนวนมากทั้งในอดีตและอนาคตก็คงถูกนำไปใช้โจมตีไม่ได้
    ถ้ามีโปรแกรม userspace พัง ก็ควรช่วยย้ายมันไปใช้โค้ด crypto ฝั่ง userspace แทน ซึ่งในความเป็นจริงหลายตัวก็เปลี่ยนไปแบบนั้นแล้ว
    ตั้งแต่แรก AF_ALG ก็แทบไม่มีประโยชน์ใช้นอกจากเป็นช่องให้ exploit
    เมื่อก่อน API สำหรับ userspace แบบนี้อาจพอทนรับได้ แต่ในยุคที่มี syzbot และ การตรวจจับบั๊กด้วย LLM แบบตอนนี้ มันคงอยู่ต่อได้ยากแล้ว

    • ฉันไม่รู้ว่า AF_ALG คืออะไรเลยไปค้นดู แล้วเจอ https://www.chronox.de/libkcapi/html/ch01s02.html ซึ่งก็มีการอธิบายเหตุผลการมีอยู่ของมันไว้พอสมควร
      เหตุผลที่ยกมาคือ ช่วยให้ userspace ใช้ ตัวเร่งฮาร์ดแวร์ ที่เข้าถึงได้เฉพาะในโหมดเคอร์เนลได้, ส่งคีย์เข้าเคอร์เนลโดยไม่ต้องปล่อยให้ค้างอยู่ในหน่วยความจำของแอปนาน ๆ, และลด footprint ได้เมื่อเทียบกับไลบรารี crypto ฝั่ง userspace ในสภาพแวดล้อมที่หน่วยความจำจำกัดอย่างระบบ embedded
      จะถือว่าเป็นเหตุผลที่ดีพอหรือไม่ฉันยังตัดสินไม่ได้ แต่อย่างน้อยก็พอมีเหตุผลรองรับอยู่
    • ชวนสงสัยว่า มันเข้าไปอยู่ในเคอร์เนลได้ยังไง
      ปกติ Linus ขึ้นชื่อว่าเข้มมากเรื่องจะรับอะไรเข้าเคอร์เนล เรื่องเบื้องหลังของ API แบบนี้น่าจะน่าสนใจทีเดียว
    • AF_ALG คือ socket interface ของ Linux ที่เปิดเผย kernel crypto API ผ่าน file descriptor
      ทำให้จัดการ hash และการเข้ารหัสผ่านการเรียก read(2)/write(2) แบบทั่วไปได้
    • สิ่งที่ฉันอยากรู้ที่สุดคือ ถ้าปิดตัวเลือกเคอร์เนลนี้แล้ว ซอฟต์แวร์ตัวไหนจะพังบ้าง

  • ดูเหมือนว่าระหว่างกระบวนการเปิดเผยข้อมูลจะมี ความสับสน อยู่พอสมควร
    ผู้ขายหลายรายดูจะไม่ได้ให้ความสำคัญกับช่องโหว่นี้มากนัก และเพราะแบบนั้นหลายดิสโทรจึงยังคงอยู่ในสถานะที่ยังไม่แพตช์
    https://access.redhat.com/security/cve/cve-2026-31431 ระบุว่า "Moderate severity", "Fix deferred" และหน้าติดตามของ Debian, Ubuntu, SUSE ก็ดูคล้ายกัน

    • ตั้งแต่ตอนที่แพตช์เข้าเคอร์เนล มันก็กลายเป็นสิ่งที่ผู้โจมตีหรือผู้สังเกตการณ์รับรู้ได้โดยพฤตินัยมาหลายสัปดาห์แล้ว
      แต่ฝั่ง upstream ไม่ได้สื่อสารอย่างชัดเจนว่านี่คือ ช่องโหว่ และ Linus กับ Greg เองก็ไม่ได้ให้ความสำคัญเชิงแนวคิดกับการจัดหมวดแบบนั้นมากนัก
    • เหตุผลที่หลายดิสโทรมองว่าเป็น ความเสี่ยงระดับปานกลาง น่าจะเพราะมันไม่ใช่การรันโค้ดจากระยะไกล แต่ต้องอาศัย การเข้าถึงในเครื่อง
      ถึงอย่างนั้น เมื่อมันยกระดับสิทธิ์เป็น root ได้จากภายในเครื่อง โดยทั่วไปก็ควรถือว่าเป็นเรื่องที่มีลำดับความสำคัญสูง
      https://ubuntu.com/security/cves/about#priority
    • ตอนนี้ RedHat เปลี่ยนเป็น Important severity และ Affected แล้ว
    • ถ้าดูตามแนวทางของ Ubuntu เอง เรื่องนี้ก็ดูควรจัดเป็น high priority แต่การระบุจริงกลับเป็น medium เลยดูไม่ค่อยสอดคล้องกัน

  • น่าเสียดายที่ในบทความไม่ได้บอกตรง ๆ ว่า เคอร์เนลเวอร์ชัน ไหนได้รับผลกระทบ และเวอร์ชันไหนแพตช์แล้ว
    ยิ่งแย่ไปอีกเพราะอันนี้เป็นโมดูลแบบ builtin จึงเอาออกง่าย ๆ ด้วย rmmod ไม่ได้
    ตอนตามหาว่า kernel 6.19.14 ของ Fedora 44 เปราะบางหรือไม่ ฉันไปเจอโพสต์ในเมลลิงลิสต์ linux-cve-announce https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    ข้างในระบุว่าได้แก้ผ่านคอมมิตนั้นใน 6.18.22, 6.19.12, และ 7.0 ตามลำดับ จึงพอใช้อ้างอิงได้

  • ถ้าคุณอยากตรวจสอบว่าได้ใช้มาตรการบรรเทาที่แนะนำด้วยการบล็อกเคอร์เนลโมดูล algif_aead ผ่านการตั้งค่า modprobe แล้วหรือยัง ก็ไม่จำเป็นต้องรันเชลล์โค้ดที่ทำให้อ่านยากทั้งก้อน
    ใช้ Python ไม่กี่บรรทัดด้านล่างเพื่อตรวจแบบอ่านง่าย ๆ ว่าโมดูลถูกโหลดจริงหรือไม่ก็ได้
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    ถ้ามาตรการบรรเทาทำงานถูกต้อง modprobe algif_aead ก็ควรล้มเหลวพร้อม error เช่นกัน

  • คงไม่มีใครรัน AI agent อัตโนมัติเต็มรูปแบบ ด้วยสิทธิ์ผู้ใช้ทั่วไปบนระบบปฏิบัติการที่ได้รับผลกระทบหรอกใช่ไหม
    ถ้าจับคู่กับ zero-day prompt injection มันอาจกลายเป็นหายนะได้เลย

    • agent ของฉันรันเป็น root อยู่แล้ว เลยไม่เห็นปัญหาอะไร
    • โชคดีที่เราไม่ได้ทำให้การติดตั้งแบบ curl | sh กลายเป็นมาตรฐานอุตสาหกรรม

  • LPE ย่อมาจาก local privilege escalation
    วงการความปลอดภัยมีตัวย่อเยอะเกินไป แม้จะเดาจากบริบทได้ แต่ก็คงดีถ้าเขียนเต็มให้ตั้งแต่แรก

    • LPE เป็นตัวย่อที่รู้จักกันค่อนข้างแพร่หลายในชุมชนความปลอดภัย จึงอาจไม่ถึงกับแย่มากที่ไม่ได้เขียนเต็ม
      แต่ถ้าเป็นบทความที่เขียนให้ผู้อ่านวงกว้าง ก็เห็นด้วยว่าควรนิยามให้ชัดเจน
      ยิ่งไปกว่านั้น บทความทั้งชิ้นยังดูเหมือน งานที่สร้างโดย AI ด้วย
    • ถ้าเขียนเพื่อผู้อ่านวงกว้าง การเขียนคำเต็มก่อนตัวย่อเป็นเรื่องพื้นฐาน แต่พวก LLM มักไม่ค่อยทำตามแนวทางนี้

  • อันนี้ค่อนข้างขำ
    หน้าเว็บเขียนว่าทำงานบน RHEL 14.3 ได้ แต่เวอร์ชันแบบนั้นไม่มีอยู่จริง
    ตอนนี้ RHEL อยู่ที่ 10.x เลยเหมือนหลุดเข้า TARDIS ไปยังไงไม่รู้

    • 14.3 น่าจะไม่ได้หมายถึงเวอร์ชันของ RHEL แต่เป็น เลขเวอร์ชัน GCC ฝั่ง Red Hat มากกว่า
      บางครั้งจะแสดงเป็น gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2) และในตัวอย่างด้านล่างก็เห็นร่องรอยคล้ายกัน
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • ในบรรทัดเดียวกันยังมี 6.12.0-124.45.1.el10_1 อยู่ด้วย ซึ่งชัดเจนว่าเป็นเคอร์เนลของ RHEL 10
      ความผิดพลาดแนวนี้กลับเป็นสิ่งที่คนมักพลาดกันเอง
      เลขยาว ๆ ที่คัดลอกมามักถูกต้อง แต่เลขง่าย ๆ กลับพิมพ์มือแล้วผิด
    • ขอโทษด้วย เรื่องนั้นจะถูกแก้ไข
      ตอนนั้นมีการเร่งรวบรวมข้อมูลเพื่ออธิบายประเด็นนี้ และก็จริง มันมีมุมทางการตลาดอยู่ด้วย
      เลยมีข้อผิดพลาดเล็ก ๆ หลุดเข้ามาบ้าง ขอบคุณที่ช่วยชี้ให้เห็น
    • ใช่ พอเห็นคำว่า "ดิสโทรที่ยืนยันแล้วโดยตรง: RHEL 14.3" ฉันก็รู้สึกทันทีว่าอย่างน้อยหน้าปล่อยข้อมูลนี้ก็ดูเป็น AI slop
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      พอเลื่อนลงไปเห็น "Talk to our security experts" ที่ท้ายหน้า ก็เริ่มรู้สึกว่า expert คนนั้นจะชื่อ Claude หรือเปล่า

  • บน RHEL 9/10 นั้น algif_aead ไม่ได้เป็นโมดูล แต่เป็น builtin จึง unload ไม่ได้
    ดังนั้นเราจึงหาวิธีรองลงมาคือ บล็อก AF_ALG ผ่าน systemd และต้องมี drop-in แยกตามแต่ละ service ที่เปิดให้ใช้งาน
    ยังมี Ansible playbook สำหรับจัดการตัวหลักอย่าง sshd และ user@ ด้วย
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • บน RHEL 9/10 ยังใช้วิธีใส่ initcall_blacklist=algif_aead_init ในตัวเลือกบูตของเคอร์เนลแล้วรีบูตได้ด้วย
      ทำแบบนั้นแล้ว exploit ใช้งานไม่ได้อีกต่อไป
    • ฉันก็คิดแนวทางคล้ายกัน แต่การบล็อกทีละ service มันให้ความรู้สึกเหมือน ตีตัวตุ่น
      ยังน่ากังวลว่าจะมีเส้นทางรันอื่นอย่าง cronjob, slurmjob หรือเปล่า และถ้าพอมีวิธีทำให้ systemd ส่งต่อข้อจำกัดนี้ไปยังทุกโปรเซสทั้งระบบแทนการตั้งราย service ได้ก็คงดีกว่า

  • ดูเหมือน exploit นี้จะใช้วิธีสลับแทนที่ SUID binary เพื่อให้รันด้วย PID 0
    แต่ตัวเว็บไซต์กลับอ้างว่าสามารถหนีจาก Kubernetes / container clusters, CI runners & build farms ได้ ทั้งที่ยังไม่เห็นคำอธิบายที่รองรับเรื่องการหนีออกจากคอนเทนเนอร์ หรือโดยเฉพาะ user namespace escape เลย
    ฉันทดสอบบน rootless Podman แล้วก็เป็นไปตามคาด คือยังหนีออกจากคอนเทนเนอร์ไม่ได้
    อีกทั้งยังอ้างว่า "ทำให้ทุก Linux distribution ที่ออกหลังปี 2017 กลายเป็น root ได้" แต่การทดสอบจริงมีแค่สี่ตัว และบน Alpine ก็ใช้ไม่ได้

    • ฝั่งเว็บไซต์ก็บอกเองว่าคำอธิบายละเอียดจะตามมาเร็ว ๆ นี้ ดังนั้นน่าจะมีขั้นตอนเพิ่มหรือการแก้ไขบางอย่างใน part 2
      มีการเกริ่นไว้ว่า "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
    • ช่องโหว่นี้สามารถเขียนทับไบต์ในหน่วยความจำของไฟล์ที่อ่านได้ จึงพอจินตนาการได้เลยว่ามันอาจใช้หนีออกจากสภาพแวดล้อมได้หลายแบบ
    • คำกล่าวอ้างว่า ทุกดิสโทรหลังปี 2017 น่าจะอิงกับข้อเท็จจริงว่าช่องโหว่นี้ถูกเพิ่มเข้ามาโดยคอมมิตช่วงครึ่งหลังของปี 2017
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      แต่ความสามารถในการนำไปใช้โจมตีจริงย่อมต่างกันไปตามว่าเป็นเมเจอร์รีลีสล่าสุด หรือเป็นเคอร์เนลสายบำรุงรักษาของสาขาเก่า
    • บทความนี้ทำลายความน่าเชื่อถือของตัวเองไปมากพอสมควร
      ถึงอย่างนั้น เมื่อฉันลองรัน PoC บนอินสแตนซ์ 24.04 เอง ช่องโหว่นี้ก็ดูเป็นของจริงและใหญ่พอตัว
      เพียงแต่จำนวนดิสโทรที่ได้รับผลกระทบดูน้อยกว่าที่อ้างไว้มาก และห่างไกลจากคำว่า ทุกดิสโทรหลังปี 2017
      ตัวอย่างเช่น ถ้าฉันตีความไม่ผิด Ubuntu แม้แต่ 16.04 EOL ก็ยังโดนเล็กน้อย และผลกระทบหลักจริง ๆ น่าจะอยู่ที่ vendor kernel ที่เพิ่งเริ่มแจกจ่ายไม่นานอย่าง linux-gcp, linux-oracle-6.7 ซึ่งอยู่ในสาย 6.17 มากกว่า
    • ต่อให้ยังอยู่ในคอนเทนเนอร์แบบ rootless ถ้าสามารถไต่ขึ้นไปถึง UID 0 จริง ได้ การหนีออกหลังจากนั้นก็ยังเป็นไปได้
      เพียงแต่ต้องมีขั้นตอนเพิ่มเติม และกรณีของ Alpine ก็อาจแค่ต้องปรับสคริปต์ ไม่ได้แปลว่าไม่มีช่องโหว่พื้นฐาน
      สุดท้ายแล้วนี่ไม่ใช่ exploit อเนกประสงค์ที่สมบูรณ์ แต่เป็น PoC

  • ตัวหน้าเว็บเองดู vibecoded หน่อย ๆ และมีกลิ่นโฆษณา แต่ช่องโหว่นั้นเป็นของจริงและระดับความเสี่ยงก็ดูสูง
    อย่างน้อยมันก็อธิบายได้ว่าทำไมวันนี้ถึงมีอัปเดตความปลอดภัยก้อนใหญ่เข้ามา ดังนั้นคงต้องยกระดับความสำคัญของการอัปเดตแล้ว

    • มันเป็น โฆษณา ที่ค่อนข้างตรงไปตรงมาจริง แต่ส่วนตัวฉันมองว่าไม่ใช่โฆษณาที่แย่
      พวกเขาหาบั๊กจริง แพตช์จริง และสร้าง คุณูปการที่มีความหมายต่อ ecosystem ของ OSS ไปพร้อมกับขายเครื่องมือความปลอดภัยของตัวเอง
    • ต่อให้ไม่มีโฆษณา คนกลุ่มนี้ก็น่าจะงานล้นมืออยู่แล้ว
      แต่ก็อดคิดไม่ได้ว่าเดี๋ยวนี้ใครจะมานั่งทำหน้าเว็บด้วยมือตัวเองทีละหน้า โดยเฉพาะถ้าเป็น นักพัฒนาเคอร์เนล ก็ยิ่งน่าเป็นไปได้