ไม่กี่วันที่ผ่านมา ได้ข่าวว่า ได้เปิดเผยรายละเอียดแล้ว ช่องโหว่ ที่ได้พบ ในการดำเนินการตามกลไก ข้อจำกัดของทรัพยากร ซีกรุ๊ป v1 ในเคอร์เนล Linux ซึ่งจัดหมวดหมู่ไว้แล้วภายใต้ CVE-2022-0492
พบช่องโหว่นี้ se สามารถใช้เพื่อออกจากภาชนะที่แยกได้ และมีรายละเอียดว่าปัญหาเกิดขึ้นตั้งแต่ลินุกซ์เคอร์เนล 2.6.24
ในบล็อกโพสต์ระบุว่า ช่องโหว่เกิดจากข้อผิดพลาดทางตรรกะในตัวจัดการไฟล์ release_agent ดังนั้นจึงไม่มีการตรวจสอบที่ถูกต้องเมื่อไดรเวอร์ถูกเรียกใช้โดยมีสิทธิ์เต็มที่
ไฟล์ release_agent ใช้เพื่อกำหนดโปรแกรมที่เคอร์เนลดำเนินการ เมื่อกระบวนการสิ้นสุดใน cgroup โปรแกรมนี้ทำงานเป็นรูทพร้อม "ความสามารถ" ทั้งหมดในเนมสเปซรูท เฉพาะผู้ดูแลระบบเท่านั้นที่มีสิทธิ์เข้าถึงการกำหนดค่า release_agent แต่ในความเป็นจริง การตรวจสอบจำกัดเฉพาะการอนุญาตให้เข้าถึงผู้ใช้ root ซึ่งไม่ได้ขัดขวางการเปลี่ยนแปลงการกำหนดค่าจากคอนเทนเนอร์หรือโดยผู้ใช้ root ที่ไม่ใช่ผู้ดูแลระบบ (CAP_SYS_ADMIN ) .
ก่อนหน้านี้ คุณลักษณะนี้จะไม่ถูกมองว่าเป็นช่องโหว่แต่สถานการณ์เปลี่ยนไปพร้อมกับเนมสเปซตัวระบุผู้ใช้ (เนมสเปซผู้ใช้) ที่ให้คุณสร้างผู้ใช้รูทแยกกันในคอนเทนเนอร์ที่ไม่ทับซ้อนกับผู้ใช้รูทของสภาพแวดล้อมหลัก
ดังนั้น สำหรับการโจมตีก็เพียงพอแล้วในคอนเทนเนอร์ที่มีผู้ใช้รูทของตัวเอง ในพื้นที่ ID ผู้ใช้แยกต่างหากเพื่อเสียบตัวจัดการ release_agent ของคุณ ซึ่งเมื่อกระบวนการเสร็จสิ้น จะทำงานด้วยสิทธิ์ทั้งหมดของสภาพแวดล้อมพาเรนต์
โดยค่าเริ่มต้น cgroupfs จะถูกเมาต์ในคอนเทนเนอร์แบบอ่านอย่างเดียว แต่ไม่มีปัญหาในการติดตั้ง pseudofs นี้ใหม่ในโหมดเขียนด้วยสิทธิ์ CAP_SYS_ADMIN หรือโดยการสร้างคอนเทนเนอร์ที่ซ้อนกันด้วยเนมสเปซผู้ใช้แยกต่างหากโดยใช้การเรียกของระบบเพื่อหยุดการแชร์ ซึ่งในสิทธิ์ของ CAP_SYS_ADMIN สามารถใช้ได้กับคอนเทนเนอร์ที่สร้างขึ้น
การโจมตี สามารถทำได้โดยมีสิทธิ์รูทในคอนเทนเนอร์แยก หรือโดยการรันคอนเทนเนอร์โดยไม่มีแฟล็ก no_new_privs ซึ่งห้ามไม่ให้ได้รับสิทธิ์เพิ่มเติม
ระบบต้องรองรับเนมสเปซที่เปิดใช้งาน ผู้ใช้ (เปิดใช้งานโดยค่าเริ่มต้นบน Ubuntu และ Fedora แต่ไม่ได้เปิดใช้งานบน Debian และ RHEL) และมีสิทธิ์เข้าถึงราก v1 cgroup (เช่น Docker เรียกใช้คอนเทนเนอร์ในกลุ่มรูท RDMA) การโจมตียังเป็นไปได้ด้วยสิทธิ์ CAP_SYS_ADMIN ซึ่งในกรณีนี้ไม่จำเป็นต้องรองรับเนมสเปซผู้ใช้และการเข้าถึงลำดับชั้นรากของ cgroup v1
นอกเหนือจากการแยกคอนเทนเนอร์ที่แยกออกมาแล้ว ช่องโหว่ยังอนุญาตให้กระบวนการที่เริ่มต้นโดยผู้ใช้รูทโดยไม่มี "ความสามารถ" หรือผู้ใช้ที่มีสิทธิ์ CAP_DAC_OVERRIDE (การโจมตีจำเป็นต้องเข้าถึงไฟล์ /sys/fs/cgroup/*/release_agent ที่เป็นของ root) เพื่อเข้าถึง "ความสามารถ" ทั้งหมดของระบบ
นอกเหนือจากคอนเทนเนอร์ ช่องโหว่ยังอาจอนุญาตให้กระบวนการของโฮสต์รูทที่ไม่มีความสามารถ หรือกระบวนการโฮสต์ที่ไม่ใช่รูทที่มีความสามารถ CAP_DAC_OVERRIDE เพื่อยกระดับสิทธิ์ให้เต็มความสามารถ การทำเช่นนี้อาจทำให้ผู้โจมตีสามารถหลีกเลี่ยงมาตรการเสริมความแข็งแกร่งที่ใช้โดยบริการบางอย่าง ซึ่งจะช่วยขจัดความสามารถเพื่อพยายามจำกัดผลกระทบหากมีการประนีประนอมเกิดขึ้น
หน่วยที่ 42 แนะนำให้ผู้ใช้อัปเกรดเป็นเวอร์ชันเคอร์เนลแบบตายตัว สำหรับคอนเทนเนอร์ที่ทำงานอยู่เหล่านั้น ให้เปิดใช้งาน Seccomp และตรวจสอบให้แน่ใจว่าได้เปิดใช้งาน AppArmor หรือ SELinux ผู้ใช้ Prisma Cloud สามารถอ้างถึงส่วน "Prisma Cloud Protections" เพื่อดูการบรรเทาผลกระทบที่ Prisma Cloud จัดหาให้
โปรดทราบว่าช่องโหว่ไม่สามารถใช้ประโยชน์ได้เมื่อใช้กลไกการป้องกัน Seccomp, AppArmor หรือ SELinux สำหรับการแยกคอนเทนเนอร์เพิ่มเติม เนื่องจาก Seccomp บล็อกการเรียกระบบ unshare() และ AppArmor และ SELinux ไม่อนุญาตให้ติดตั้ง cgroupfs ในโหมดเขียน
สุดท้ายนี้ ควรสังเกตว่าได้รับการแก้ไขแล้วในเคอร์เนลเวอร์ชัน 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 และ 4.9.301 คุณสามารถติดตามการอัพเดทแพ็คเกจในการแจกจ่ายในหน้าเหล่านี้: debian, SUSE, อูบุนตู, RHEL, Fedora, Gentoo, Arch ลินุกซ์.
ในที่สุด หากคุณสนใจที่จะทราบข้อมูลเพิ่มเติมคุณสามารถตรวจสอบรายละเอียดได้ในไฟล์ ลิงค์ต่อไปนี้