ช่องโหว่รูทในชุดเครื่องมือการจัดการแพ็คเกจ Snap

Qualys ได้ระบุช่องโหว่ระดับรุนแรงที่สามในปีนี้ (CVE-2022-3328) ในยูทิลิตี้ snap-confine ซึ่งมาพร้อมกับ SUID root flag และถูกเรียกโดยกระบวนการ snapd เพื่อสร้างสภาพแวดล้อมที่ปฏิบัติการได้สำหรับแอปพลิเคชันที่เผยแพร่ในแพ็คเกจที่มีในตัวเอง ในรูปแบบสแนป ช่องโหว่ดังกล่าวทำให้ผู้ใช้ที่ไม่มีสิทธิ์ในพื้นที่สามารถเรียกใช้โค้ดในฐานะรูทในการกำหนดค่าเริ่มต้นของ Ubuntu ปัญหานี้ได้รับการแก้ไขแล้วในการเปิดตัว snapd 2.57.6 การอัปเดตแพ็คเกจได้รับการเผยแพร่สำหรับ Ubuntu ทุกสาขาที่รองรับ

สิ่งที่น่าสนใจคือ ช่องโหว่ดังกล่าวถูกนำมาใช้ในกระบวนการแก้ไขช่องโหว่ที่คล้ายกันในเดือนกุมภาพันธ์ใน snap-confine นักวิจัยสามารถเตรียมช่องโหว่ในการทำงานที่ให้การเข้าถึงรูทใน Ubuntu Server 22.04 ซึ่งนอกเหนือจากช่องโหว่แบบ snap-confine ยังเกี่ยวข้องกับช่องโหว่สองรายการในกระบวนการ multipathd (CVE-2022-41974, CVE-2022-41973) เกี่ยวข้องกับการข้ามการตรวจสอบสิทธิ์เมื่อส่งคำสั่งพิเศษและการจัดการลิงก์สัญลักษณ์ที่ไม่ปลอดภัย

ช่องโหว่ใน snap-confine เกิดจากสภาวะการแข่งขันในฟังก์ชัน must_mkdir_and_open_with_perms() ที่ถูกเพิ่มเพื่อป้องกันการแทนที่ไดเร็กทอรี /tmp/snap.$SNAP_NAME ด้วยลิงก์สัญลักษณ์หลังจากเจ้าของตรวจสอบ แต่ก่อนที่จะเมานต์การเรียกของระบบ ถูกเรียกให้รวมไดเร็กทอรีเข้ากับแพ็คเกจในรูปแบบ snap การรักษาความปลอดภัยที่เพิ่มคือการเปลี่ยนชื่อไดเร็กทอรี /tmp/snap.$SNAP_NAME ไปเป็นไดเร็กทอรีอื่นใน /tmp ด้วยชื่อแบบสุ่ม หากมีอยู่ และไม่ได้เป็นเจ้าของโดยผู้ใช้ root

เมื่อใช้ประโยชน์จากการดำเนินการเปลี่ยนชื่อไดเร็กทอรี /tmp/snap.$SNAP_NAME นักวิจัยได้ใช้ประโยชน์จากข้อเท็จจริงที่ว่า snap-confine ยังสร้างไดเร็กทอรี /tmp/snap.rootfs_XXXXXX สำหรับรูทของเนื้อหาของแพ็คเกจ snap ด้วย ส่วน "XXXXXX" ของชื่อถูกเลือกแบบสุ่มโดย mkdtemp() แต่แพ็คเกจชื่อ "rootfs_XXXXXX" สามารถผ่าน sc_instance_name_validate ได้ (เช่น แนวคิดคือให้ $SNAP_NAME ตั้งค่าเป็น "rootfs_XXXXXX" จากนั้นการดำเนินการเปลี่ยนชื่อจะส่งผลให้มีการเขียนทับ ไดเร็กทอรี /tmp/snap.rootfs_XXXXXX ที่มี snap root)

เพื่อให้บรรลุถึงการใช้งานพร้อมกันของ /tmp/snap.rootfs_XXXXXX และการเปลี่ยนชื่อ /tmp/snap.$SNAP_NAME จึงมีการเริ่มต้น snap-confine สองอินสแตนซ์ ทันทีที่อินสแตนซ์แรกสร้าง /tmp/snap.rootfs_XXXXXX กระบวนการจะบล็อกและอินสแตนซ์ที่สองที่มีชื่อแพ็กเกจ rootfs_XXXXXX จะเริ่มทำงาน ทำให้ไดเร็กทอรีชั่วคราวของอินสแตนซ์ที่สอง /tmp/snap.$SNAP_NAME กลายเป็น /tmp/snap ไดเร็กทอรีราก .rootfs_XXXXXX ของอินสแตนซ์แรก ทันทีหลังจากการเปลี่ยนชื่อ อินสแตนซ์ที่สองหยุดทำงาน และ /tmp/snap.rootfs_XXXXXX ถูกแทนที่ด้วยการจัดการสภาพการแข่งขัน เช่นเดียวกับการใช้ประโยชน์จากช่องโหว่ในเดือนกุมภาพันธ์ หลังจากการเปลี่ยนแปลง การล็อกการดำเนินการจะถูกลบออกจากอินสแตนซ์แรก และผู้โจมตีสามารถควบคุมไดเร็กทอรี root ของ snap ได้อย่างสมบูรณ์

ขั้นตอนสุดท้ายคือการสร้าง symlink /tmp/snap.rootfs_XXXXXX/tmp ซึ่งถูกใช้โดยฟังก์ชัน sc_bootstrap_mount_namespace() เพื่อผูกเมานต์ไดเร็กทอรีจริงที่เขียนได้ /tmp ไปยังไดเร็กทอรีใด ๆ ในระบบไฟล์ เนื่องจากการเรียก mount() เป็นไปตามนั้น ลิงก์สัญลักษณ์ก่อนทำการติดตั้ง การติดตั้งดังกล่าวถูกบล็อกโดยข้อจำกัดของ AppArmor แต่เพื่อหลีกเลี่ยงการบล็อกนี้ ช่องโหว่ดังกล่าวจึงใช้ประโยชน์จากช่องโหว่เสริมสองช่องโหว่ใน multipathd

ที่มา: opennet.ru

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