มอร์-หวู่ (Moru) เจ้าหน้าที่ความปลอดภัยข้อมูลระดับสูงของ 23pds เปิดเผยเมื่อวันที่ 8 พฤษภาคม ว่าระบบปฏิบัติการ Linux มีช่องโหว่การยกระดับสิทธิ์อย่างร้ายแรงที่ชื่อว่า Dirty Frag โดยมีการเผยแพร่รายละเอียดครบถ้วนและโค้ดสำหรับการใช้งานแล้ว ทำให้ผู้ใช้ท้องถิ่นที่มีสิทธิ์ต่ำสามารถรับสิทธิ์ผู้ดูแลระบบระดับ root ของระบบที่ได้รับผลกระทบได้โดยตรง โดยไม่จำเป็นต้องมีเงื่อนไขเฉพาะของระบบ มาตรการบรรเทาเหตุฉุกเฉินคือการปิดการใช้งานโมดูลทั้งสามตัว ได้แก่ esp4, esp6 และ rxrpc
Dirty Frag ทำไมอันตรายมาก: ข้อบกพร่องเชิงตรรกะ อัตราความสำเร็จสูง ไม่มีแพตช์
Dirty Frag จัดเป็นข้อบกพร่องเชิงตรรกะที่แน่นอน ไม่ใช่การโจมตีที่ไม่เสถียรซึ่งต้องพึ่งพาเงื่อนไขการแข่งขัน (race conditions) จึงทำให้ความสำเร็จสูงมากและทำซ้ำได้อย่างเสถียร ผู้โจมตีเพียงแค่รันโปรแกรมขนาดเล็ก ก็สามารถรับสิทธิ์ root ของระบบเป้าหมายได้ทันที กระบวนการทั้งหมดจะไม่ทำให้แกนระบบ (kernel) ล่ม และแทบตรวจจับด้วยการเฝ้าระวังทั่วไปได้ยาก
ช่องโหว่ถูกส่งโดยนักวิจัยด้านความปลอดภัยต่อทีม Linux kernel เมื่อวันที่ 30 เมษายน แต่ก่อนการแก้ไขจะเสร็จสมบูรณ์ มี “บุคคลที่สามที่ไม่เกี่ยวข้อง” เผยแพร่ข้อมูลเชิงลึกและโค้ดสำหรับการใช้งานไว้ล่วงหน้า ส่งผลให้คำสั่งห้ามด้านความปลอดภัยถูกบังคับให้ยกเลิก ชุมชนความปลอดภัยโดยรวมมองว่านี่อาจหมายความว่าผู้โจมตีที่เป็นอันตรายอาจเริ่มใช้งานช่องโหว่นี้อย่างจริงจังแล้ว
เมื่อพิจารณาหลักการทางเทคนิค Dirty Frag มีกลไกคล้ายกับช่องโหว่ Copy Fail ที่สร้างความเสียหายอย่างกว้างขวางในแวดวงเซิร์ฟเวอร์ของ Linux ในปัจจุบัน ทั้งคู่ใช้การแทรกตัวอธิบาย (descriptor) ของหน้าแคช (page cache) เข้าไปในปฏิบัติการแบบศูนย์คัดลอก (zero-copy) เพื่อดำเนินการโจมตี ช่องโหว่ต้นตอ “xfrm-ESP Page-Cache Write” ถูกนำเข้ามาตั้งแต่การคอมมิตของ kernel ในปี 2017 ที่ชื่อ cac2661c53f3 เนื่องจาก Ubuntu แก้ไขช่องโหว่นี้ด้วย AppArmor ลิงก์ PoC จึงเชื่อมโยงกับช่องโหว่ที่สอง “RxRPC Page-Cache Write” (คอมมิต 2dc334f1a63a) เพื่อให้มั่นใจว่าการโจมตีก็ยังได้ผลบนระบบ Ubuntu เช่นกัน
ขอบเขตที่ได้รับผลกระทบ: รายชื่อกระจายตามกระแสหลักที่ยืนยันแล้ว
ยืนยันว่ามีระบบ Linux distribution ที่ได้รับผลกระทบบ้าง (ส่วนหนึ่ง) ดังนี้:
· Ubuntu 24 และ Ubuntu 26 (รวมถึง AppArmor ผ่านช่องโหว่ที่สอง)
· Arch Linux (รวมถึงเวอร์ชันที่อัปเดตก็ยืนยันว่าได้รับผลกระทบ)
· RHEL (Red Hat Enterprise Linux)
· OpenSUSE
· CentOS Stream
· Fedora
· AlmaLinux
· CachyOS (คอร์เวอร์ชัน 7.0.3-1-cachyos ได้รับการยืนยันว่าเรียกใช้งานได้)
· WSL2 (Windows Subsystem for Linux) ก็ยืนยันว่ามีผลเช่นกัน
มาตรการบรรเทาเหตุฉุกเฉิน: คำสั่งเฉพาะสำหรับการปิดใช้งานโมดูลทั้งสามตัว
ก่อนที่จะแพตช์จากทางการจะออกเผยแพร่ วิธีบรรเทาที่มีประสิทธิภาพที่สุดคือปิดใช้งานโมดูลทั้งสามตัว ได้แก่ esp4, esp6 และ rxrpc โมดูลทั้งสามตัวนี้เกี่ยวข้องกับฟังก์ชันเครือข่ายของ IPSec เป็นหลัก เว้นแต่เซิร์ฟเวอร์จะเป็นทั้งไคลเอนต์หรือเซิร์ฟเวอร์ของ IPSec (คือใช้สำหรับการสื่อสารเข้ารหัสที่เลเยอร์เครือข่าย) ไม่เช่นนั้นการปิดใช้งานจะแทบไม่กระทบงานปกติ
รันคำสั่งต่อไปนี้เพื่อปิดการใช้งานโมดูล: sh -c “printf ‘install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n’ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true”
หลังรันเสร็จ โปรดติดตามประกาศด้านความปลอดภัยของแต่ละ Linux distribution อย่างใกล้ชิด และเมื่อมีการเผยแพร่แพตช์อย่างเป็นทางการให้รีบปรับปรุงระบบทันที
คำถามที่พบบ่อย
ตอนนี้ช่องโหว่ Dirty Frag มีแพตช์อย่างเป็นทางการแล้วหรือยัง?
จนถึงขณะนี้ ทางการยังไม่ได้เผยแพร่แพตช์ใดๆ และไม่พบการคอมมิตสำหรับการแก้ไขในคอร์หลักของ Linux สาเหตุคือคำสั่งห้ามด้านความปลอดภัยถูกทำลายก่อนที่การเตรียมแพตช์จะเสร็จ ทำให้รายละเอียดช่องโหว่ถูกเปิดเผย ทั้งที่งานซ่อมยังไม่เสร็จสมบูรณ์ ผู้ดูแลระบบควรติดตามประกาศด้านความปลอดภัยของ Linux distribution อย่างใกล้ชิด และเมื่อแพตช์ออกแล้วให้ปรับปรุงระบบทันที
การปิดโมดูล esp4, esp6 และ rxrpc จะกระทบการทำงานปกติของเซิร์ฟเวอร์หรือไม่?
โมดูลทั้งสามตัวนี้เกี่ยวข้องกับโปรโตคอล IPSec เป็นหลัก หากเซิร์ฟเวอร์ไม่ใช่ไคลเอนต์หรือเซิร์ฟเวอร์ของ IPSec (คือไม่ได้ใช้สำหรับการสื่อสารเข้ารหัสที่เลเยอร์เครือข่าย) การปิดใช้งานจะแทบไม่กระทบงานทั่วไปอย่างบริการ Web, ฐานข้อมูล, โหนดเข้ารหัส ฯลฯ นี่จึงเป็นวิธีบรรเทาเหตุฉุกเฉินที่ปลอดภัยที่สุดและมีผลกระทบน้อยที่สุดในตอนนี้
ทำไมครั้งนี้ช่องโหว่ถึงถูกเปิดเผยโดยที่ยังไม่มีแพตช์?
แนวปฏิบัติในอุตสาหกรรมคือ “responsible disclosure” คือหลังจากนักวิจัยด้านความปลอดภัยส่งข้อมูลช่องโหว่ให้กับผู้ผลิตแล้ว มักจะรอจนกว่าการทำแพตช์จะเสร็จ ก่อนค่อยเปิดเผยรายละเอียด ช่องโหว่นี้ถูกส่งเมื่อวันที่ 30 เมษายน แต่ “บุคคลที่สามที่ไม่เกี่ยวข้อง” ได้รั่วไหลข้อมูลเชิงลึกไว้ก่อน จึงทำให้คำสั่งห้ามถูกทำลาย นักวิจัยคาดการณ์ว่าอาจเป็นไปได้ที่ผู้โจมตีที่เป็นอันตรายได้เริ่มใช้ช่องโหว่นี้อย่างจริงจังก่อนแล้ว และนี่คือปัจจัยที่ทำให้คำสั่งห้ามในท้ายที่สุดถูกยกเลิก
