มีการระบุช่องโหว่ใหม่สองรายการในระบบย่อย eBPF ซึ่งช่วยให้คุณสามารถเรียกใช้ตัวจัดการภายในเคอร์เนล Linux ในเครื่องเสมือนพิเศษที่มี JIT ช่องโหว่ทั้งสองทำให้สามารถรันโค้ดของคุณด้วยสิทธิ์เคอร์เนล นอกเครื่องเสมือน eBPF ที่แยกออกมาได้ ข้อมูลเกี่ยวกับปัญหาได้รับการเผยแพร่โดยทีมงาน Zero Day Initiative ซึ่งดำเนินการแข่งขัน Pwn2Own ซึ่งในระหว่างปีนี้แสดงให้เห็นว่ามีการโจมตีสามครั้งบน Ubuntu Linux ที่ใช้ช่องโหว่ที่ไม่รู้จักก่อนหน้านี้ (ไม่ว่าช่องโหว่ใน eBPF จะเกี่ยวข้องกับการโจมตีเหล่านี้หรือไม่ก็ตาม) .
- CVE-2021-3490 - ช่องโหว่นี้เกิดจากการขาดการตรวจสอบนอกขอบเขตแบบ 32 บิต เมื่อดำเนินการระดับบิต AND, OR และ XOR ใน eBPF ALU32 ผู้โจมตีสามารถใช้ประโยชน์จากข้อผิดพลาดนี้เพื่ออ่านและเขียนข้อมูลนอกขอบเขตของบัฟเฟอร์ที่จัดสรร ปัญหาเกี่ยวกับการดำเนินการ XOR ปรากฏขึ้นโดยเริ่มจากเคอร์เนลเวอร์ชัน 5.7-rc1 และ AND และ OR - เริ่มต้นจาก 5.10-rc1
- CVE-2021-3489 - ช่องโหว่นี้เกิดจากข้อผิดพลาดในการใช้งาน Ring Buffer และเนื่องมาจากข้อเท็จจริงที่ว่าฟังก์ชัน bpf_ringbuf_reserve ไม่ได้ตรวจสอบความเป็นไปได้ที่ขนาดของขอบเขตหน่วยความจำที่จัดสรรอาจน้อยกว่าขนาดจริง ของริงบุฟ ปัญหาปรากฏขึ้นตั้งแต่รีลีส 5.8-rc1
สามารถติดตามสถานะของการแพตช์ช่องโหว่ในการแจกแจงได้ในหน้าเหล่านี้: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch) การแก้ไขยังมีให้ใช้งานในรูปแบบแพตช์ (CVE-2021-3489, CVE-2021-3490) ไม่ว่าปัญหาจะสามารถถูกโจมตีได้หรือไม่นั้นขึ้นอยู่กับว่าผู้ใช้สามารถเข้าถึงการเรียกระบบ eBPF ได้หรือไม่ ตัวอย่างเช่น ในการกำหนดค่าเริ่มต้นใน RHEL การใช้ประโยชน์จากช่องโหว่ต้องการให้ผู้ใช้มีสิทธิ์ CAP_SYS_ADMIN
แยกกันเราสามารถสังเกตช่องโหว่อื่นในเคอร์เนล Linux - CVE-2021-32606 ซึ่งอนุญาตให้ผู้ใช้ท้องถิ่นเพิ่มสิทธิ์ของตนไปที่ระดับรูท ปัญหาปรากฏชัดตั้งแต่เคอร์เนล Linux 5.11 และเกิดจากสภาวะการแข่งขันในการใช้งานโปรโตคอล CAN ISOTP ซึ่งทำให้สามารถเปลี่ยนพารามิเตอร์การรวมซ็อกเก็ตได้เนื่องจากขาดการตั้งค่าการล็อคที่เหมาะสมในฟังก์ชัน isotp_setsockopt() เมื่อประมวลผลแฟล็ก CAN_ISOTP_SF_BROADCAST
หลังจากปิดซ็อกเก็ต ISOTP การเชื่อมโยงกับซ็อกเก็ตผู้รับยังคงมีผลอยู่ ซึ่งสามารถใช้โครงสร้างที่เกี่ยวข้องกับซ็อกเก็ตต่อไปได้หลังจากที่หน่วยความจำที่เกี่ยวข้องกับซ็อกเก็ตนั้นถูกปลดปล่อย (ใช้งานหลังเลิกใช้งานเนื่องจากการเรียกไปยังโครงสร้าง isotp_sock ที่ได้รับการปลดปล่อยแล้วเมื่อมีการเรียกใช้ isotp_rcv()) ด้วยการจัดการข้อมูล คุณสามารถแทนที่ตัวชี้ไปที่ฟังก์ชัน sk_error_report() และรันโค้ดของคุณในระดับเคอร์เนลได้
ที่มา: opennet.ru