ช่องโหว่ในเคอร์เนล Linux ที่ถูกหาประโยชน์จากระยะไกลผ่าน Bluetooth

พบช่องโหว่ (CVE-2022-42896) ในเคอร์เนล Linux ซึ่งอาจใช้เพื่อจัดระเบียบการเรียกใช้โค้ดจากระยะไกลในระดับเคอร์เนลโดยการส่งแพ็กเก็ต L2CAP ที่ออกแบบมาเป็นพิเศษผ่านทาง Bluetooth นอกจากนี้ ยังมีการระบุปัญหาอื่นที่คล้ายกัน (CVE-2022-42895) ในตัวจัดการ L2CAP ซึ่งอาจนำไปสู่การรั่วไหลของเนื้อหาหน่วยความจำเคอร์เนลในแพ็คเก็ตที่มีข้อมูลการกำหนดค่า ช่องโหว่แรกเกิดขึ้นตั้งแต่เดือนสิงหาคม 2014 (เคอร์เนล 3.16) และครั้งที่สองตั้งแต่เดือนตุลาคม 2011 (เคอร์เนล 3.0) ช่องโหว่ได้รับการแก้ไขแล้วในเคอร์เนล Linux รุ่น 6.1.0, 6.0.8, 4.9.333, 4.14.299, 4.19.265, 5.4.224, 5.10.154 และ 5.15.78 คุณสามารถติดตามการแก้ไขในการแจกแจงในหน้าต่อไปนี้: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch

เพื่อแสดงให้เห็นถึงความเป็นไปได้ในการโจมตีระยะไกล จึงได้มีการเผยแพร่ช่องโหว่ต้นแบบที่ทำงานบน Ubuntu 22.04 ในการโจมตี ผู้โจมตีต้องอยู่ในระยะสัญญาณ Bluetooth ไม่จำเป็นต้องจับคู่ล่วงหน้า แต่ต้องเปิดใช้งาน Bluetooth บนคอมพิวเตอร์ สำหรับการโจมตี แค่รู้ที่อยู่ MAC ของอุปกรณ์ของเหยื่อก็เพียงพอแล้ว ซึ่งสามารถระบุได้โดยการดมกลิ่น หรือคำนวณตามที่อยู่ MAC ของ Wi-Fi ในอุปกรณ์บางชนิด

ช่องโหว่แรก (CVE-2022-42896) เกิดจากการเข้าถึงพื้นที่หน่วยความจำที่ว่างแล้ว (ใช้งานฟรี) ในการใช้งานฟังก์ชัน l2cap_connect และ l2cap_le_connect_req - หลังจากสร้างช่องทางผ่านการเรียกกลับ new_connection ล็อคไม่ได้ถูกตั้งค่า สำหรับมัน แต่มีการตั้งค่าตัวจับเวลา (__set_chan_timer ) เมื่อหมดเวลาการเรียกใช้ฟังก์ชัน l2cap_chan_timeout และล้างช่องสัญญาณโดยไม่ตรวจสอบความสมบูรณ์ของงานกับช่องในฟังก์ชัน l2cap_le_connect*

การหมดเวลาเริ่มต้นคือ 40 วินาที และสันนิษฐานว่าสภาวะการแข่งขันไม่สามารถเกิดขึ้นได้พร้อมกับความล่าช้าดังกล่าว แต่กลับกลายเป็นว่าเนื่องจากข้อผิดพลาดอื่นในตัวจัดการ SMP จึงเป็นไปได้ที่จะทำการเรียกตัวจับเวลาทันทีและบรรลุผล สภาพการแข่งขัน. ปัญหาใน l2cap_le_connect_req อาจทำให้หน่วยความจำเคอร์เนลรั่วไหล และใน l2cap_connect อาจทำให้เกิดการเขียนทับเนื้อหาของหน่วยความจำและรันโค้ดได้ การโจมตีประเภทแรกสามารถทำได้โดยใช้ Bluetooth LE 4.0 (ตั้งแต่ปี 2009) และการโจมตีประเภทที่สองเมื่อใช้ Bluetooth BR/EDR 5.2 (ตั้งแต่ปี 2020)

ช่องโหว่ที่สอง (CVE-2022-42895) เกิดจากหน่วยความจำรั่วไหลในฟังก์ชัน l2cap_parse_conf_req ซึ่งสามารถใช้เพื่อรับข้อมูลเกี่ยวกับตัวชี้ไปยังโครงสร้างเคอร์เนลจากระยะไกลโดยการส่งคำขอการกำหนดค่าที่สร้างขึ้นเป็นพิเศษ ฟังก์ชัน l2cap_parse_conf_req ใช้โครงสร้าง l2cap_conf_efs ซึ่งหน่วยความจำที่จัดสรรไม่ได้ถูกเตรียมใช้งานล่วงหน้า และด้วยการจัดการแฟล็ก FLAG_EFS_ENABLE ทำให้สามารถรวมข้อมูลเก่าจากสแต็กในแพ็กเก็ตได้ ปัญหาจะปรากฏบนระบบที่สร้างเคอร์เนลด้วยตัวเลือก CONFIG_BT_HS เท่านั้น (ปิดใช้งานโดยค่าเริ่มต้น แต่เปิดใช้งานบนบางรุ่น เช่น Ubuntu) การโจมตีที่ประสบความสำเร็จยังต้องตั้งค่าพารามิเตอร์ HCI_HS_ENABLED ผ่านอินเทอร์เฟซการจัดการให้เป็นจริง (ไม่ได้ใช้เป็นค่าเริ่มต้น)

ที่มา: opennet.ru

เพิ่มความคิดเห็น