ช่องโหว่ของเคอร์เนล Linux ไม่มีการแจ้งเตือนล่วงหน้าไปยังดิสทริบิวชัน

 (openwall.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • CopyFail ซึ่งเป็นช่องโหว่ยกระดับสิทธิ์แบบโลคัลของเคอร์เนล Linux จัดอยู่ในกลุ่มช่องโหว่ “make-me-root” ของเคอร์เนลช่วงหลังที่ ร้ายแรงที่สุดกลุ่มหนึ่ง
  • ปัญหานี้ถูกนำเข้ามาใน commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 ของเวอร์ชัน 4.14 และถูกแก้ไขใน 6.18.22, 6.19.12, 7.0
  • เวอร์ชัน 6.19.12 และ 6.18.22 ออกรวม การ backport แพตช์แก้ไข เมื่อวันที่ 11 เมษายน แต่ Longterm 6.12, 6.6, 6.1, 5.15, 5.10 ในเวลานั้นยังไม่ได้รับการแก้ไข
  • แพตช์นี้ไม่สามารถ clean apply กับเคอร์เนลรุ่นเก่าได้ และในสถานการณ์ที่ต้องรีบปล่อยแพตช์ อาจใช้ แพตช์ปิดใช้งานโมดูล authencesn ของ IPSec เป็นมาตรการชั่วคราว
  • ช่องโหว่ของเคอร์เนล Linux จะไม่มีการแจ้งเตือนล่วงหน้าไปยังดิสทริบิวชัน เว้นแต่ผู้รายงานจะส่งเรื่องเข้า linux-distros ML และในกรณีนี้ก็ไม่มี heads-up เกิดขึ้น

ขอบเขตผลกระทบและสถานะการแก้ไขของ CVE-2026-31431

  • CopyFail เป็นช่องโหว่ยกระดับสิทธิ์แบบโลคัลของเคอร์เนล Linux และจัดอยู่ในกลุ่มช่องโหว่ “make-me-root” ของเคอร์เนลช่วงหลังที่ร้ายแรงที่สุดกลุ่มหนึ่ง
  • ปัญหานี้ถูกนำเข้ามาใน commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 ของ 4.14 และถูกแก้ไขใน 6.18.22, 6.19.12, 7.0 ตามลำดับ
  • commit แก้ไขของ 6.18.22
  • commit แก้ไขของ 6.19.12
  • commit แก้ไขของ 7.0
  • เวอร์ชัน 6.19.12 และ 6.18.22 ถูกปล่อยออกมาเมื่อวันที่ 11 เมษายนพร้อม การ backport แพตช์แก้ไข
  • Longterm 6.12, 6.6, 6.1, 5.15, 5.10 ในเวลานั้นยังไม่ได้รับการแก้ไข และก็ไม่ปรากฏใน upstream stable queue เช่นกัน
  • หากเป็นปัญหาที่ถูกนำเข้ามาตั้งแต่ปี 2017 ก็จำเป็นต้องตรวจสอบว่าเคอร์เนลรุ่นเก่าก็ได้รับผลกระทบด้วยหรือไม่

การแจ้งล่วงหน้าให้ดิสทริบิวชันและมาตรการชั่วคราว

  • แพตช์แก้ไขนี้ไม่สามารถ clean apply กับเคอร์เนลรุ่นเก่าได้
  • มีการพยายาม backport เพื่อใช้ในสถานการณ์ที่จำเป็นต้องปล่อยแพตช์ทันที แต่เนื่องจากมี การเปลี่ยนแปลง API บางส่วน จึงยากที่จะดำเนินการต่อด้วยความมั่นใจ
  • เป็นมาตรการชั่วคราว สามารถใช้แพตช์ปิดใช้งานโมดูล authencesn ของ IPSec ได้ และแม้ไม่ใช่ผู้เชี่ยวชาญ IPSec ก็ยังนับว่าใกล้เคียงกับ “ทางเลือกที่แย่น้อยกว่า”
  • 0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch: แพตช์ปิดใช้งานโมดูล authencesn สำหรับรับมือ CVE-2026-31431
  • ช่องโหว่ของเคอร์เนล Linux จะไม่มีการแจ้งเตือนล่วงหน้าไปยังดิสทริบิวชัน เว้นแต่ผู้รายงานจะส่งเรื่องเข้า linux-distros ML
  • ในกรณีนี้ ไม่มี heads-up ผ่าน linux-distros ML เกิดขึ้น

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

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

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

  • Sam James ผู้เขียนบทความที่ลิงก์ไว้เป็นนักพัฒนา Gentoo
    อย่างไรก็ดี เรื่องนี้เกือบเข้าขั้นหายนะ และการเปิดเผย exploit ก่อนที่ดิสโทรต่าง ๆ จะปล่อยแพตช์ออกมานั้นไร้ความรับผิดชอบอย่างมาก
    ไม่รู้ว่ามีผู้ให้บริการ shared hosting ถูกแฮ็กไปแล้วมากแค่ไหนจากเรื่องนี้
    อีกเรื่องที่น่ากังวลคือดูเหมือนจะไม่มีการสื่อสารระหว่าง kernel security team กับ maintainer ของดิสโทร
    คนทั่วไปย่อมคาดหวังว่าฝ่ายแรกจะเป็นผู้แจ้งฝ่ายหลัง แต่ในความเป็นจริงกลับดูเหมือนว่าคนที่พบช่องโหว่ต้องเป็นผู้รับผิดชอบเอง

    • ผมไม่เห็นว่าการ เปิดเผยหลังจากส่งแพตช์ให้ผู้ถูกรายงานแล้ว 30 วัน จะมีปัญหาในตัวมันเอง
      อ้างอิงคือ Google Project Zero ก็ใช้นโยบายคล้ายกันแบบ “90+30”: https://projectzero.google/vulnerability-disclosure-policy.h...
      ปัญหาที่แท้จริงคือไม่มีช่องทางสื่อสารระหว่าง kernel security team กับ maintainer ของดิสโทร
      คนที่ค้นพบช่องโหว่ไม่ควรต้องมีภาระต้องรายงานให้ downstream ทุกรายแยกกัน
      ทีม kernel ควรแจ้งรายชื่อผู้รับผิดชอบด้านความปลอดภัยของดิสโทรเกี่ยวกับความร้ายแรงของแพตช์และกำหนดการเปิดเผยในอีก 30 วัน
    • การเปิดเผยครั้งนี้ใกล้เคียงกับ การตลาด มากกว่าความปลอดภัย
      ในหน้าเผยแพร่ยังมีข้อความอย่าง “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]”
      เป็นวิธีที่ยิ่งทำให้เกิดความสับสนมากเท่าไร ผลิตภัณฑ์ก็ดูน่าสนใจมากขึ้นเท่านั้น
    • ในฐานะผู้ใช้และผู้ดูแลระบบ ผมไม่เห็นด้วยกับคำว่า “ไร้ความรับผิดชอบอย่างมาก”
      คำว่า Responsible Disclosure เป็นคำที่ออกแบบเชิงภาษามาอย่างดีพอ ๆ กับ “Secure Boot” และในทางปฏิบัติดูเหมือนมีไว้เพื่อจัดการชื่อเสียงขององค์กรตัวกลางอย่างบริษัทหรือมูลนิธิที่คั่นอยู่ระหว่างผมกับคอมพิวเตอร์ของผม
      พวกเขาสนใจจะกันไม่ให้มีคนพูดว่า “RHEL มีช่องโหว่”, “Ubuntu มีช่องโหว่” มากกว่าจะสนใจว่าคอมพิวเตอร์แต่ละเครื่องของผมเสี่ยงหรือไม่
      ช่องโหว่มีอยู่แล้ว ดังนั้นผมคิดว่าการรู้ถึงความเสี่ยงและมีโอกาสลดความเสี่ยงนั้นดีกว่าการรอให้มีการแก้ไขแบบเงียบ ๆ
      กล่าวคือ ผมคิดว่าการเปิดเผยทันทีเท่านั้นที่ไม่ใช่ทางเลือกที่ไร้ความรับผิดชอบ
    • ไม่ว่าคุณจะมีจุดยืนอย่างไรต่อขั้นตอนการเปิดเผย ถ้าผู้ให้บริการ hosting รายใดถูกเจาะด้วยเรื่องนี้ โครงสร้างของเขาก็แพ้อยู่แล้ว
      การรัน tenant workload ที่ไม่ไว้วางใจกันภายใต้ single shared kernel เดียวนั้นไม่เหมาะสม
      Kernel LPE ไม่ใช่เรื่องหายาก และกรณีนี้เพียงแค่เรียบง่ายและพกพาได้ดีเป็นพิเศษ ขณะที่ capability ขั้นพื้นฐานเองก็แทบเป็นสินค้าโภคภัณฑ์แบบ CNE อยู่แล้ว
    • Linux kernel ไม่เหมาะจะใช้เป็นขอบเขตความปลอดภัย
      ถ้าจะทำ shared hosting โดยไม่อยากถูกแฮ็ก ควรใช้วิธีอื่นอย่าง gVisor หรือ Firecracker VM
      ระบบสำคัญที่ใช้มันเป็นขอบเขตความปลอดภัยจริง ๆ มีประมาณ Android ซึ่งมีทั้งการขออนุมัติผู้ใช้ก่อนติดตั้ง APK, นโยบาย SELinux และ seccomp ที่เข้มงวด, รวมถึงการ hardening ของ GrapheneOS ช่วยบรรเทา
      และในกรณีนี้การบรรเทาก็ได้ผล: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

  • ผมไม่เข้าใจเหตุผลของการพูดทำนองว่า “กรณีช่องโหว่ใน Linux kernel ดิสโทรจะไม่ได้รับการแจ้งล่วงหน้า เว้นแต่ reporter จะนำไปที่ linux-distros ML โดยตรง”
    การคาดหวังให้ reporter ต้องประสานงานกับดิสโทรต่าง ๆ โดยตรงนั้นตั้งอยู่บนสมมติฐานว่าต้องมีความรู้ระดับสูงเกี่ยวกับโครงการ Linux
    ผู้แจ้งช่องโหว่ไม่ควรต้องรับผิดชอบไปทำงานกับผู้ใช้ downstream ทั้งหมดของ Linux ด้วยตัวเอง
    ถ้าจะเอาแบบนั้น ก็ต้องติดต่อผู้ผลิตอุปกรณ์ทุกรายที่ใช้ Linux ในอุปกรณ์ของตัวเองโดยตรงด้วยหรือไม่
    ผมคิดว่าผู้แจ้งทำเพียงแค่รายงานให้ Linux อย่างรับผิดชอบและรอจนมีแพตช์รวมเข้าไปก็เพียงพอแล้ว
    ภายในโครงการ Linux ควรมีคนที่มีอำนาจและความรับผิดชอบต่อช่องโหว่ด้านความปลอดภัย และคนเหล่านั้นก็ควรเป็นผู้แจ้ง downstream distro

    • ยิ่งเป็นเช่นนั้นเพราะมีการขออย่างชัดเจนด้วยว่า reporter อย่าเพิ่งแจ้งทีมดิสโทรก่อน
      https://docs.kernel.org/process/security-bugs.html
      As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
    • reporter มีเวลาพอจะเข้าไปตรวจสอบและเอ่ยถึงดิสโทรเฉพาะอย่าง Ubuntu/RHEL/SUSE บนเว็บไซต์ของตัวเอง
      อย่างน้อยการแจ้งทีมความปลอดภัยของดิสโทรเหล่านั้นก็น่าจะเป็นพฤติกรรมที่รับผิดชอบ
    • ยากจะมองว่าการที่ reporter สร้างเว็บไซต์ซึ่งระบุชื่อ Ubuntu, RedHat, Amazon และ SUSE อย่างชัดเจน แต่กลับไม่แจ้งพวกเขานั้นเป็นเรื่องสมเหตุสมผล
      ก็ดูไม่น่าเป็นไปได้อยู่แล้วว่าเขาจะไม่รู้ว่าดิสโทรเหล่านั้นเป็น downstream ของทีม kernel
    • มันอาจไม่ใช่ข้อบังคับ แต่ผมคิดว่าเราทุกคนต้องเดือดร้อนมากขึ้นเพราะ reporter สนใจชื่อเสียงมากกว่าการ remediation ที่ปลอดภัย
    • การหาวิธีรายงานประเด็นความปลอดภัยแบบนี้ให้ Linux distro นั้นง่ายมาก
      แค่ค้น Google ก็เจอ: https://share.google/aimode/eihDKXZJy94Z5lC1p
      การไม่คิดจะทำสิ่งนี้และปล่อยให้ทุกคนเปิดรับ exploit จึงเป็นเรื่องที่เข้าใจได้ยาก และในบางเขตอำนาจศาลก็ไม่แปลกเลยถ้าจะถือเป็นอาชญากรรมร้ายแรง

  • การแลกเปลี่ยนที่น่าสนใจที่สุดเกี่ยวกับ disclosure อยู่ในลิงก์นี้
    https://www.openwall.com/lists/oss-security/2026/05/01/3
    นี่คือคำตอบของ greg k-h ที่ว่า “เราไม่สามารถแจ้งใครล่วงหน้าได้ เพราะถ้าทำเช่นนั้นก็ต้องแจ้งทุกคนในทุกเรื่อง และนั่นคือนโยบายเดียวที่หน่วยงานกฎหมายและรัฐบาลต่าง ๆ ยอมให้เราดำเนินการได้”

    • ผมชอบ Linux นะ แต่คิดว่านี่เป็นนโยบายที่งี่เง่า

  • เราควรเลิกโทษ reporter แล้วไปเรียกร้องให้แก้ กระบวนการของ kernel แทน
    Linux kernel ไม่ใช่โครงการเล่น ๆ อีกต่อไปแล้ว และมีพนักงานเต็มเวลาที่หลายบริษัทจ้างไว้
    การแจ้งดิสโทรควรเป็นสิ่งที่คนเหล่านั้นจัดการ ไม่ใช่โยนให้บุคคลทั่วไปแบบสุ่ม

    • ถ้าถึงขั้นตั้งชื่อดิสโทรเฉพาะว่าได้รับผลกระทบในโพสต์บล็อกสำหรับการประกาศ ซึ่งแทบจะเป็นงานการตลาด ก็ถือว่าเหมาะสมและควรคาดหวังได้ว่าจะมีการ แจ้งเตือนล่วงหน้า ก่อนเผยแพร่
      ถ้าไม่ได้ใส่คำพูดอย่าง RHEL 14 ไว้แบบนั้น ก็คงไม่โดนวิจารณ์หนักถึงขนาดนี้
      นี่ไม่ใช่นักวิจัยความปลอดภัยอิสระหรือฝั่งวิชาการ แต่เป็นบริษัทความปลอดภัยที่มีฝ่ายสื่อสารมืออาชีพ และกำลังชี้นิ้วไปที่ distro maintainer
    • ดิสโทรและนักพัฒนา kernel ควรสื่อสารกันเรื่องแพตช์ high severity และเร่งดำเนินการก็จริง
      แต่เพราะ reporter ไม่รอให้สิ่งนั้นเกิดขึ้น จึงอาจมีคนจริง ๆ ได้รับความเสียหาย และความรับผิดชอบนั้นอยู่ที่ reporter
    • การรายงานช่องโหว่กับการเผยแพร่ exploit ที่ทรงพลัง ซึ่งใครก็หยิบไปใช้ได้ทันทีนั้นเป็นคนละเรื่องกันโดยสิ้นเชิง
      การปล่อยมันสู่สาธารณะโดยไม่แจ้งดิสโทรหลักก่อนเป็นเรื่องไร้ความรับผิดชอบ

  • ผมได้โพสต์ workaround แบบ eBPF สำหรับคนที่ใช้ kernel ซึ่ง AF_ALG ไม่ได้เป็นโมดูลแต่ลิงก์เข้าไปใน kernel โดยตรงแล้ว: https://github.com/Dabbleam/CVE-2026-31431-mitigation
    ตอนนี้รันอยู่ใน production และช่วยบรรเทาการโจมตีได้ โดยจนถึงตอนนี้ยังไม่เห็นผลข้างเคียงที่ไม่คาดคิด

  • ผมคิดว่า nosuid และน่าจะรวม nodev ด้วย ควรเป็น filesystem mount option เริ่มต้น
    /dev เองก็เป็น devtmpfs แบบพิเศษอยู่แล้ว และ /dev ขั้นต่ำของ initrd ก็ถ้าจำเป็นสามารถ mount rootfs ของ initrd tmpfs แบบกำหนด dev และ suid อย่างชัดเจนได้
    การปล่อยให้ SUID binary “มีอยู่” ได้ทุกที่เป็นความเสี่ยงด้านความปลอดภัยอย่างมาก
    เวลาคุณ mount สื่อเก็บข้อมูลภายนอก คุณจะตรวจสอบได้อย่างไรว่า SUID binary ใน block device นั้นเป็นอันตรายหรือไม่
    ยิ่งไปกว่านั้น exploit นี้ดูเหมือนจะทำงานได้ก็ต่อเมื่อผู้ใช้ที่รัน SUID binary สามารถอ่าน binary นั้นได้ด้วย
    ไม่มีเหตุผลที่ผู้ใช้ non-root จะต้องมีสิทธิ์อ่าน SUID binary
    NixOS จัดการเรื่องนี้ได้ถูกต้อง
    ใน /nix/store ซึ่งเป็นไดเรกทอรีติดตั้งแพ็กเกจทั่วไปจะไม่มี SUID และเพราะแพ็กเกจไม่รั่วออกไปข้างนอก จึงใช้ nosuid กับ mountpoint อื่น ๆ ได้อย่างปลอดภัย
    ข้อยกเว้นมีเพียงไดเรกทอรี /run/wrappers.$hash ที่มีวัตถุประสงค์เดียวสำหรับเก็บ executable-only SUID wrapper อย่างปลอดภัย

    • ผมก็ไม่ชอบ suid เหมือนกัน แต่ในกรณีนี้ suid ไม่ใช่ปัญหาหลัก
      บั๊กที่ถูก exploit นั้นโดยพื้นฐานแล้วทำให้เกิดการทำ page cache poisoning แบบตามอำเภอใจได้
      ถึงจุดนั้นเกมก็จบแล้ว และการ patch โปรแกรม suid อาจเป็นแค่วิธีที่ง่ายที่สุดในการได้ root shell แต่ไม่ใช่วิธีเดียว
    • proof of concept exploit ก็เป็นเพียงการสาธิต attack vector แบบหนึ่งตามชื่อของมันเท่านั้น
      ยังมีวิธีอื่นอีกมาก
      ถ้าเป้าหมายคือแค่กัน exploit ต้นแบบ วิธีง่ายกว่าอย่าง blacklist ก็พอมีได้ แต่ไม่ได้ทำให้ปลอดภัยขึ้นจริง
      ช่องโหว่นี้ทำให้สามารถจัดการ page cache ได้
      คุณสามารถแก้ ld.so เพื่อ hook กับ system call ใดก็ได้, เปลี่ยน uid เป็น 0, หรือยกระดับสิทธิ์ด้วยวิธีอื่นอีกมาก
      mount point ไม่ได้เกี่ยวกับปัญหานี้
      แน่นอนว่าการกัน suid ออกจากพื้นที่ที่ผู้ใช้เขียนได้ และกันไม่ให้อ่านไฟล์ suid เป็นความคิดที่ดีเสมอ แต่เป็นด้วยเหตุผลอื่น
      NixOS ก็ไม่ได้แก้ช่องโหว่นี้ และยังคงมีช่องโหว่เช่นเดียวกับดิสโทรอื่น
    • ถ้าไม่มีสิทธิ์อ่านก็จะรัน binary ไม่ได้ ซึ่งไม่สมเหตุสมผล
      การจะรัน binary ต้องอ่านมันจากดิสก์เข้าไปโหลดในหน่วยความจำ
      จริง ๆ แล้วถ้า binary ตัวใดมีสิทธิ์อ่านแต่ไม่มีสิทธิ์ execute โดยตรง คุณก็ยังเรียก linker โดยตรงเพื่อรันมันได้
      ตัวอย่างเช่นเรียกแบบ /bin/ld.so.1 /path/to/binary แล้ว linker จะอ่านและโหลด binary จากนั้นกระโดดไปยัง entry point โดยไม่ต้องเรียก exec()

  • ลิงก์ Bleeping Computer ด้านล่างมีมาตรการรับมือที่เป็นไปได้จนกว่าจะมีแพตช์พร้อม
    https://www.bleepingcomputer.com/news/security/new-linux-cop...

    • workaround นี้ใช้ได้เฉพาะกับ kernel ที่คอมไพล์โค้ดที่ได้รับผลกระทบเป็นโมดูลเท่านั้น
      RHEL, Fedora และ Gentoo ต่างก็ตั้งค่าให้ build โค้ดนี้เข้า kernel โดยตรงทั้งหมด
      หากไม่มีแพตช์หรือการเปลี่ยน config ดิสโทรเหล่านั้นก็จะยังคงมีช่องโหว่ต่อไป ตามที่ Sam สื่อไว้เกี่ยวกับ Gentoo
    • บน RedHat และดิสโทรสายพันธุ์ของมัน โค้ดที่ได้รับผลกระทบถูก คอมไพล์แบบ static ไม่ใช่โมดูล ดังนั้นมาตรการนี้จึงใช้ไม่ได้

  • NixOS ก็ไม่ได้รับการแจ้งเตือนเช่นกัน
    https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

    • ไม่มีดิสโทรใดได้รับการแจ้งเตือนเลย

  • Hyperbola GNU ปลอดภัยเพราะยังใช้ Python 3.8 อยู่ด้วยเหตุผลทางการเมืองและเรื่องเสถียรภาพ

  • Ubuntu ออกแพตช์แล้ว และมีการทดสอบทั้งก่อนและหลังแพตช์เสร็จสิ้น