Copy Fail: ช่องโหว่ของ Linux ที่ให้สิทธิ์เข้าถึงระดับ root ผ่านการแคชหน้าเว็บ

ประเด็นสำคัญ:
  • ผู้โจมตีเปิดซ็อกเก็ต AF_ALG และร้องขออัลกอริทึมการตรวจสอบสิทธิ์
  • ผู้โจมตีใช้ฟังก์ชัน splice() เพื่อส่งข้อมูลจากแคชของไฟล์เป้าหมาย (เช่น /usr/bin/su) ไปยังซ็อกเก็ต ข้อมูลเหล่านี้จะกลายเป็นส่วนหนึ่งของรายการแฮชเอาต์พุต (สามารถเขียนได้)
  • ผู้โจมตีส่งข้อความ (sendmsg) ที่มีข้อมูลรับรองความถูกต้องที่เกี่ยวข้อง (Associated Authenticated Data หรือ AAD) ที่ออกแบบมาอย่างเป็นอันตราย โดยไบต์ที่ 4-7 จะมีข้อมูลที่พวกเขาต้องการเขียน (เช่น โค้ดที่เป็นอันตราย)
  • เมื่อเริ่มกระบวนการถอดรหัส ระบบตรวจสอบสิทธิ์จะดึงข้อมูล 4 ไบต์จาก AAD และเขียนข้อมูลเหล่านั้นลงในส่วนท้ายของบัฟเฟอร์ชั่วคราว เนื่องจากการปรับปรุงประสิทธิภาพแบบ in-place ส่วนท้ายของบัฟเฟอร์นี้จึงชี้ไปยังหน้าแคชไฟล์โดยตรง
  • การเข้ารหัสล้มเหลว (ข้อความที่เข้ารหัสไม่ถูกต้อง) แต่การเขียนข้อมูลขนาด 4 ไบต์ได้เกิดขึ้นแล้วและจะไม่ถูกย้อนกลับ
  • ผู้โจมตีทำซ้ำกระบวนการนี้เพื่อแทรกโค้ดของตน เมื่อเรียกใช้ /usr/bin/su เคอร์เนลจะโหลดเวอร์ชันที่แก้ไขแล้วจากหน่วยความจำ และเรียกใช้โค้ดที่แทรกเข้าไปด้วยสิทธิ์ระดับรูท

การคัดลอกล้มเหลว

ความปลอดภัยของ Linux กำลังเผชิญกับความท้าทายอีกครั้งหลังจากการค้นพบ ช่องโหว่ CVE-2026-31431 หรือที่เรียกว่า "Copy Fail" โดยทีมนักวิจัยจาก Xint Code ปัญหาการออกแบบนี้ไม่ได้เป็นเพียงข้อบกพร่องทางทฤษฎีเท่านั้น ฟังก์ชันนี้ช่วยให้ผู้ใช้ภายในเครื่องที่ไม่มีสิทธิ์พิเศษสามารถยกระดับสิทธิ์และเข้าถึงระบบได้อย่างเต็มที่ ในฐานะผู้ใช้ระดับสูงสุด ด้วยวิธีการที่คาดเดาได้และเงียบเชียบ

นักวิจัยระบุว่าช่องโหว่นี้ถูกใช้ประโยชน์สำเร็จแล้วในระบบปฏิบัติการชั้นนำ เช่น Ubuntu, Amazon Linux, RHEL และ SUSE ซึ่งเป็นการยืนยันว่า ระบบใดๆ ที่ใช้เคอร์เนลเวอร์ชันที่ใหม่กว่า 4.14 และ ทำต่อไป การเปิดใช้งานการรองรับซ็อกเก็ต AF_ALG อาจก่อให้เกิดช่องโหว่ได้ ต่อการโจมตีครั้งนี้

การดำเนินการแบบ In-Place และการล้นของแคชหน้าเว็บ

เกี่ยวกับการตัดสินนั้น มีการกล่าวถึงว่า ที่มาของการปรับปรุงประสิทธิภาพนี้มาจากสิ่งที่ได้รับการแนะนำในปี 2017 ภายใน API การเข้ารหัสลับของเคอร์เนล (AF_ALG) การปรับเปลี่ยนครั้งนี้ ฉันต้องการกำจัดช่วงเวลาการโหลดข้อมูลที่ไม่จำเป็นออกไป การดำเนินการเข้ารหัสแบบตรวจสอบความถูกต้อง (AEAD) โดยตรงในพื้นที่หน่วยความจำเดียวกัน ซึ่งเรียกว่าการดำเนินการแบบ "in-place"

El ปัญหาสำคัญเกิดขึ้นเมื่อนำการปรับแต่งนี้ไปใช้ร่วมกับฟังก์ชัน splice() วิธีการนี้ถ่ายโอนข้อมูลระหว่างตัวระบุไฟล์โดยการถ่ายโอนการอ้างอิงโดยตรงไปยังแคชเพจของเคอร์เนลแทนที่จะคัดลอกข้อมูลจริง เมื่อร้องขอการถอดรหัส โครงสร้างหน่วยความจำได้รับการกำหนดค่าเพื่อให้บัฟเฟอร์ปลายทาง ซึ่งควรจะเป็นพื้นที่ชั่วคราวสำหรับผู้ใช้ กลับเชื่อมโยงโดยตรงกับเพจแคชที่มีข้อมูลไฟล์ระบบ

การตรวจสอบสิทธิ์และการเขียนข้อมูลนอกเหนือขอบเขตของหน่วยความจำ

El สาเหตุสุดท้ายของช่องโหว่นี้มาจากการทำงานที่ผิดปกติของอัลกอริทึมการตรวจสอบสิทธิ์ แตกต่างจากขั้นตอนการเข้ารหัสลับอื่นๆ ที่เคารพขอบเขตของบัฟเฟอร์ปลายทางอย่างเคร่งครัด อัลกอริทึมเฉพาะนี้ใช้พื้นที่หน่วยความจำของผู้ใช้เป็นพื้นที่ทำงานชั่วคราว (แผ่นจดบันทึก) เพื่อจัดเรียงลำดับไบต์ใหม่ระหว่างการคำนวณแท็กการตรวจสอบสิทธิ์

ในกระบวนการนี้ อัลกอริทึมจะเขียนข้อมูลเกินขีดจำกัดที่กำหนดไว้สำหรับพื้นที่เอาต์พุตไปสี่ไบต์ เนื่องจากการเพิ่มประสิทธิภาพแบบในตัวและการสร้างสายโซ่อ้างอิงโดยฟังก์ชัน splice()ข้อความที่เขียนดูเหมือนไม่มีพิษภัยนี้ กลับล้ำเข้าไปในขอบเขตความทรงจำของผู้ใช้ และลงจอดโดยตรงบนหน้าแคชเคอร์เนลที่เชื่อมโยงกับไฟล์ที่กำลังประมวลผลอยู่

ลำดับความล้มเหลวเชิงตรรกะนี้ ช่องโหว่นี้ทำให้ผู้โจมตีสามารถเขียนทับข้อมูลสี่ไบต์ในตำแหน่งแคชที่กำหนดได้อย่างตามอำเภอใจ จำนวนหน้าสำหรับไฟล์ใดๆ ก็ตามที่สามารถอ่านได้ โดยการส่งคำขอที่คำนวณไว้เป็นชุดๆ ผู้โจมตีสามารถแทรกโค้ดที่เป็นอันตรายได้ ในไฟล์ปฏิบัติการที่สำคัญเวอร์ชันในหน่วยความจำซึ่งมีการตั้งค่าบิต suid ไว้ เช่น เครื่องมือสลับผู้ใช้

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

การแก้ไขปัญหาฉุกเฉินและมาตรการบรรเทาผลกระทบ

เนื่องจากคำตัดสินนี้มีความร้ายแรงมาก ทีมบำรุงรักษาได้ทำการอัปเดตฉุกเฉินแล้ว ซึ่งทางออกที่เด็ดขาดนั้นอยู่ที่... ยกเลิกการปรับแต่งแบบในตัวภายในไฟล์ algif_aead.c โดยแยกรายการหน่วยความจำต้นทางและปลายทางออกจากกันอย่างเคร่งครัด เพื่อป้องกันไม่ให้หน้าเว็บที่ถูกแคชไว้ไปอยู่ในพาธที่สามารถเขียนได้

แพทช์เหล่านี้ได้ถูกรวมเข้ากับเคอร์เนลเวอร์ชัน 6.18.22, 6.19.12 และ 7.0 แล้ว และกำลังถูกนำไปใช้กับสาขาการสนับสนุนระยะยาว สำหรับผู้ดูแลระบบที่ไม่สามารถรีสตาร์ทหรืออัปเดตเซิร์ฟเวอร์ได้ทันที ขอแนะนำให้ปิดใช้งานโมดูลเคอร์เนล algif_aead หากมีการคอมไพล์จากภายนอก หรือจำกัดการสร้างซ็อกเก็ต AF_ALG อย่างเข้มงวดโดยใช้มาตรการรักษาความปลอดภัย เช่น SELinux ซึ่งเป็นเกราะป้องกันที่ช่วยปกป้องอุปกรณ์ Android รุ่นปัจจุบันจากภัยคุกคามนี้

สุดท้ายนี้ หากคุณสนใจเรียนรู้เพิ่มเติม สามารถดูรายละเอียดได้ที่ลิงก์ต่อไปนี้


เพิ่มเป็นแหล่งข้อมูลที่ต้องการใน Google