สรุปสั้น

มีการเปิดเผยช่องโหว่ร้ายแรงในส่วน traffic-control subsystem ของ Linux kernel ที่เปิดทางให้ผู้ใช้ทั่วไปที่ไม่มีสิทธิ์พิเศษ (local unprivileged user) สามารถยกระดับสิทธิ์ขึ้นเป็น root บนระบบที่ได้รับผลกระทบได้ ช่องโหว่นี้คือ CVE-2026-46331 ที่ถูกตั้งฉายาว่า “pedit COW” เป็นช่องโหว่ประเภทเขียนข้อมูลเกินขอบเขต (out-of-bounds write) ในแอ็กชันแก้ไขแพ็กเก็ต (act_pedit) ซึ่งทำให้หน่วยความจำ page-cache ที่ใช้ร่วมกันเสียหาย จุดที่อันตรายที่สุดคือเทคนิคโจมตีนี้ไม่แตะไฟล์บนดิสก์เลย แต่จะเข้าไปวางยาสำเนาแคชของไบนารี setuid root (เช่น /bin/su) ที่อยู่ในหน่วยความจำ ฉีดเพย์โหลดขนาดเล็กเข้าไป แล้วรันอิมเมจที่ถูกดัดแปลงนั้นด้วยสิทธิ์ root ผลคือการตรวจสอบความสมบูรณ์ของไฟล์ (file-integrity check) จะให้ผลปกติทุกอย่าง ในขณะที่ root shell ถูกเปิดไปแล้ว มี proof-of-concept ที่ใช้งานได้จริงปรากฏออกมาภายในเวลาเพียงวันเดียวหลังจากที่ CVE ถูกกำหนดเมื่อวันที่ 16 มิถุนายน โดยบริษัท Red Hat จัดระดับความรุนแรงไว้ที่ระดับ important

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 26 มิถุนายน พ.ศ. 2569 ว่าช่องโหว่ CVE-2026-46331 หรือ “pedit COW” สามารถถูกใช้ยกระดับสิทธิ์จากผู้ใช้ทั่วไปสู่ root ได้ เงื่อนไขที่จำเป็นต่อการโจมตีมีสองอย่าง คือโมดูล act_pedit ต้องสามารถโหลดได้ และต้องเปิดใช้ unprivileged user namespaces ซึ่งจะมอบความสามารถด้านเครือข่ายระดับ namespace (CAP_NET_ADMIN) ให้ผู้โจมตี อันเป็นสิ่งที่จำเป็นต่อการกระตุ้นบั๊กนี้ บนเป้าหมายที่ทดสอบทั้ง RHEL และ Debian พบว่ามีเงื่อนไขทั้งสองอย่างนี้อยู่

เครื่องมือ tc (traffic-control) ของ Linux สามารถเขียนทับ header ของแพ็กเก็ตขณะกำลังส่งผ่านได้ด้วยแอ็กชันที่ชื่อ pedit ฟังก์ชันในเคอร์เนลที่ทำหน้าที่นี้คือ tcf_pedit_act() ซึ่งโดยปกติต้องทำสำเนาข้อมูลแบบส่วนตัวก่อนจะแก้ไข ตามรูปแบบ copy-on-write มาตรฐาน แต่ปัญหาคือฟังก์ชันนี้ตรวจสอบช่วงที่เขียนได้เพียงครั้งเดียว ก่อนที่ค่า offset สุดท้ายจะถูกคำนวณ ขณะที่ edit key บางตัวจะคลี่ค่า offset ของมันออกมาตอน runtime เท่านั้น เมื่อเกิดเหตุการณ์เช่นนี้ การเขียนจะตกไปอยู่นอกพื้นที่ที่ถูกคัดลอกแบบส่วนตัว ทำให้เคอร์เนลไปแก้ไขหน้า page-cache ที่ใช้ร่วมกันแทนที่จะเป็นสำเนาส่วนตัว และถ้าหน้านั้นเป็นของไฟล์ที่ถูกแคชไว้ อิมเมจในหน่วยความจำของไฟล์นั้นก็จะถูกทำให้เสียหาย

รูปแบบช่องโหว่นี้คุ้นเคยกันดี เพราะ Dirty Pipe, Copy Fail, DirtyClone และ Dirty Frag ล้วนมีรูปแบบเดียวกัน คือ fast path ของเคอร์เนลเขียนลงในหน้าหน่วยความจำที่ตัวเองไม่ได้เป็นเจ้าของแต่ผู้เดียว และ page cache คือผู้รับเคราะห์ สิ่งที่ใหม่ในกรณีนี้คือจุดเริ่มต้นของการโจมตี ที่ผู้ใช้ทั่วไปสามารถตั้งค่า tc actions จากภายใน user namespace ซึ่งมอบ CAP_NET_ADMIN ที่การโจมตีต้องการให้

รายละเอียดช่องโหว่

ผู้เขียน PoC รายงานว่าสามารถโจมตียกระดับจากผู้ใช้ทั่วไปสู่ root ได้บน RHEL 10 และ Debian 13 (trixie) ซึ่งเปิดใช้ unprivileged user namespaces เป็นค่าเริ่มต้น ส่วน Ubuntu 24.04 ต้องใช้เส้นทางผ่าน AppArmor profile ที่ยังอนุญาต user namespaces อยู่ ขณะที่ Ubuntu 26.04 บล็อกเส้นทางนี้ตามค่าเริ่มต้น เนื่องจาก AppArmor profile จำกัด unprivileged user namespaces ไว้ แม้เคอร์เนลพื้นฐานจะยังมีช่องโหว่อยู่ก็ตาม

การแก้ไขแยกตามผู้จำหน่าย Debian ได้แก้ไข trixie ผ่านช่องทาง security channel แล้ว แต่ Debian 11 และ 12 ยังถูกระบุว่ามีช่องโหว่ Ubuntu ระบุว่าเวอร์ชันที่รองรับตั้งแต่ 18.04 ถึง 26.04 ยังมีช่องโหว่ ณ วันที่ 25 มิถุนายน ส่วนบริษัท Red Hat ระบุว่า RHEL 8, 9 และ 10 ได้รับผลกระทบ โดยไม่มี RHEL 7 อยู่ในประกาศ จุดที่น่ากังวลคือการแก้ไขถูกส่งเข้า netdev mailing list ตั้งแต่ปลายเดือนพฤษภาคมในฐานะแพตช์แก้ปัญหาข้อมูลเสียหายธรรมดา รายละเอียดที่สามารถนำไปโจมตีได้จึงถูกเปิดเผยอยู่บน mailing list สาธารณะนานหลายสัปดาห์ โดยไม่มี CVE และไม่มีคำเตือนด้านความปลอดภัย CVE ถูกกำหนดเมื่อแพตช์ถูก merge ในวันที่ 16 มิถุนายน และ proof-of-concept ที่ใช้โจมตีได้ก็ตามมาภายในวันเดียว

ผลกระทบต่อไทย

ช่องโหว่นี้กระทบ Linux distribution หลักที่องค์กรไทยใช้งานแพร่หลายทั้ง RHEL, Debian และ Ubuntu ระบบที่มีความเสี่ยงสูงเป็นพิเศษคือระบบที่คำว่า “local user” ไม่ได้หมายถึงผู้ใช้ที่ไว้ใจได้ เช่น เซิร์ฟเวอร์แบบ multi-tenant, CI/CD runner, โหนด Kubernetes, build worker และเครื่องในห้องแล็บหรือเครื่องวิจัยที่ใช้ร่วมกัน องค์กรไทยที่ให้บริการคลาวด์ โฮสติง หรือมีระบบที่ผู้ใช้หลายรายเข้าถึงเชลล์ได้ ควรถือว่าช่องโหว่นี้เป็นความเสี่ยงเร่งด่วน เพราะผู้ใช้ทั่วไปเพียงรายเดียวก็สามารถยึดสิทธิ์ root ทั้งเครื่องได้ และยากต่อการตรวจจับเพราะไม่ทิ้งร่องรอยบนดิสก์

คำแนะนำ

แนวทางที่ดีที่สุดคือติดตั้งเคอร์เนลที่แพตช์แล้วและรีบูตเครื่อง โดยให้ความสำคัญกับระบบที่ผู้ใช้ภายในไม่ใช่ผู้ใช้ที่ไว้วางใจก่อน หากยังแพตช์ไม่ได้ มีมาตรการบรรเทาสองทางที่ตัดวงจรการโจมตีได้ ทางแรกคือบนระบบที่ไม่จำเป็นต้องใช้กฎ tc pedit ให้ตรวจสอบว่าโมดูลถูกใช้งานอยู่หรือไม่ด้วย lsmod | grep act_pedit แล้วบล็อกไม่ให้โหลดด้วยคำสั่ง echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf ทางที่สองคือปิด unprivileged user namespaces (ตั้ง user.max_user_namespaces=0 บน RHEL หรือ kernel.unprivileged_userns_clone=0 บน Debian/Ubuntu) ซึ่งจะตัดความสามารถระดับ namespace ที่การโจมตีต้องการ แต่จะทำให้ rootless container, CI sandbox บางตัว และเบราว์เซอร์แบบ sandbox ใช้งานไม่ได้ จึงควรทดสอบก่อน ทั้งนี้ เนื่องจากการเขียนทับมุ่งเป้าที่หน่วยความจำแคช การตรวจ file-integrity อาจจับไม่ได้ การล้าง page cache ด้วย echo 3 > /proc/sys/vm/drop_caches ช่วยล้างสำเนาที่ถูกวางยาในหน่วยความจำได้ แต่ไม่ช่วยกับ root shell ที่ผู้โจมตีเปิดไปแล้ว ดังนั้นหากสงสัยว่าถูกโจมตี ควรถือว่าเครื่องนั้นถูกยึดครองแล้ว

แหล่งอ้างอิง