เมื่อเร็ว ๆ นี้ ข้อมูลช่องโหว่ที่เปิดเผย (CVE-2022-29582) ในการใช้งานอินเทอร์เฟซ I/O แบบอะซิงโครนัส io_uring ที่รวมอยู่ในเคอร์เนล Linux ตั้งแต่เวอร์ชัน 5.1 ซึ่งอนุญาตให้ผู้ใช้ที่ไม่มีสิทธิพิเศษสามารถเป็นรูทบนระบบได้ แม้ว่าจะทำการใช้ประโยชน์จากคอนเทนเนอร์
เป็นมูลค่าการกล่าวขวัญว่า บอกว่ามีรายงานช่องโหว่เมื่อ 3 เดือนที่แล้ว (ประมาณต้นเดือนพฤษภาคมปีนี้) แต่ข้อมูลและการเปิดเผยฉบับสมบูรณ์เพิ่งออกเมื่อไม่นานนี้เอง
ส่วนเรื่องความเปราะบางนั้นได้กล่าวไว้ว่า เกิดขึ้นเมื่อเข้าถึงบล็อกของหน่วยความจำที่ว่างอยู่แล้วปรากฏในเคอร์เนล Linux ที่เริ่มต้นด้วยสาขา 5.10
เกี่ยวกับช่องโหว่ CVE-2022-29582
ช่องโหว่นี้ อนุญาตให้เข้าถึงหน่วยความจำที่ว่าง อันเป็นผลมาจากสภาวะการแข่งขันเมื่อจัดการการหมดเวลาในฟังก์ชัน io_flush_timeouts() ซึ่งe ลบรายการหมดเวลา จากรายการและยกเลิกโดยไม่ต้องตรวจสอบการสร้างและการลบการหมดเวลา ณ จุดนั้น
ผู้อื่นได้ให้คำอธิบายทั่วไปที่อัปเดตของ io_uring แล้ว พวกเขาอธิบายได้ดีกว่าที่เราทำพันเท่า ดังนั้นเราจะครอบคลุมระบบย่อยให้ครอบคลุมมากขึ้น (ดูบทความ Grapl Security และบทความ Flatt Security นี้สำหรับการแนะนำที่ดี)
สิ่งที่สำคัญกว่านั้นคือ ฟิลด์ opcode กำหนดประเภทของการดำเนินการที่จะดำเนินการ สำหรับแต่ละ "opcode" ที่ต้องการ ฟิลด์ fd จะระบุ file descriptor เพื่อดำเนินการ I/O ที่ร้องขอ การเรียกระบบ I/O ปกติเกือบทั้งหมด (อ่าน, sendto ฯลฯ) มี opcode แบบอะซิงโครนัสเทียบเท่า แต่ละฟิลด์สามารถมีบทบาทที่แตกต่างกันขึ้นอยู่กับการดำเนินการ
เมื่อดึงข้อมูลจาก SQ แล้ว SQE จะถูกแปลงเป็นการแทนค่าภายในที่อธิบายโดย struct io_kiocb (การเรียกกลับของเคอร์เนลอินพุต/เอาต์พุต) วัตถุเหล่านี้มักเรียกว่าคำขอ
struct io_kiocb ใช้เทียบเท่ากับ "พร้อมสำหรับการเปิดตัว" ของ SQE ซึ่งอิงตามโดยที่ตัวอธิบายไฟล์ใด ๆ ได้รับการแก้ไขเป็น struct ไฟล์ * แนบข้อมูลรับรองผู้ใช้บุคลิกภาพ (ซึ่งแกนจะทำงาน) ฯลฯ .
หลังจากการดำเนินการที่ร้องขอเสร็จสมบูรณ์ จะถูกเขียนไปยังคิวการเสร็จสิ้น (CQ) รายการที่สอดคล้องกับ SQE รายการดังกล่าวเรียกว่ารายการคิวการเสร็จสิ้น (CQE) และมีฟิลด์ต่างๆ เช่น รหัสข้อผิดพลาดและค่าผลลัพธ์ แอปพลิเคชันพื้นที่ผู้ใช้สามารถสำรวจ CQ สำหรับรายการใหม่เพื่อตรวจสอบว่า SQE ที่ส่งเสร็จสิ้นการประมวลผลหรือไม่และผลลัพธ์เป็นอย่างไร
ได้กล่าวไว้ว่า มีบางสถานการณ์ที่ง่ายต่อการแทนที่วัตถุ เกี่ยวกับความคืบหน้า แต่มีข้อ จำกัด สองประการ:
- LT' จะต้องถูกกำหนดและเริ่มต้นในหน้าต่างการแข่งขัน นั่นคือ หลังจากที่ LT ถูกปล่อย แต่ก่อนที่จะถึงจุดหนึ่งใน LT ที่ไม่สามารถเข้าถึงได้อีกต่อไป
- LT' สามารถเป็นวัตถุ io_kiocb อื่นได้เท่านั้น เนื่องจากการแยกฮีป โดยที่วัตถุในฮีปถูกแยกตามประเภทของมัน จึงยากเกินไปที่จะกำหนดใหม่ให้เป็นวัตถุประเภทอื่นภายในหน้าต่างการแข่ง
นักวิจัยได้เตรียมการหาประโยชน์จากการทำงาน ซึ่งไม่ต้องการการรวมเนมสเปซตัวระบุผู้ใช้ (เนมสเปซผู้ใช้) สำหรับการดำเนินการและสามารถให้การเข้าถึงรูทไปยังโฮสต์เมื่อผู้ใช้ที่ไม่มีสิทธิพิเศษเปิดใช้งานการหาช่องโหว่ในคอนเทนเนอร์แยก
การเอารัดเอาเปรียบของเรากำหนดเป้าหมายเคอร์เนลเวอร์ชัน 5.10.90 ซึ่งเป็นเวอร์ชันที่ Google ใช้งานจากระยะไกลในขณะนั้น เราต้องปรับการหาช่องโหว่ของเราให้เข้ากับข้อกำหนดเฉพาะของเซิร์ฟเวอร์ (4 คอร์ Skylake Xeon @ 2.80Ghz, 16GiB RAM) แต่ด้วยการปรับแต่งบางอย่าง เครื่องใดก็ตามที่ใช้เคอร์เนลที่มีช่องโหว่ควรใช้ประโยชน์ได้
การเอารัดเอาเปรียบยังทำงานในสภาพแวดล้อม nsjail แยกจากการกระจาย Google COS (Container Optimized OS) ตาม Chromium OS และใช้งานบน Google Cloud Platform บนเครื่องเสมือน Compute Engine ช่องโหว่นี้ออกแบบมาเพื่อทำงานกับเคอร์เนลสาขาตั้งแต่ 5.10 ถึง 5.12 สุดท้ายนี้ ขอบอกว่า ปัญหาได้รับการแก้ไขในเดือนเมษายนในการอัปเดต 5.10.111, 5.15.34 และ 5.17.3
สุดท้ายนี้ หากคุณสนใจที่จะทราบข้อมูลเพิ่มเติมเกี่ยวกับช่องโหว่นี้ คุณสามารถปรึกษากับสื่อเผยแพร่ที่ทำขึ้นได้ ในลิงค์ต่อไปนี้.