มีการค้นพบช่องโหว่ใหม่ใน Systemd

พบช่องโหว่ใน systemd ซึ่งอธิบายไว้แล้วใน (CVE-2019-6454), อะไร อนุญาตให้ทำให้กระบวนการเริ่มต้นการควบคุม (PID1) ปิดกั้น เมื่อส่งข้อความที่สร้างขึ้นเป็นพิเศษไปยังผู้ใช้ที่ไม่มีสิทธิพิเศษผ่าน D-Bus

ลอส นักพัฒนา Red Hat ยังไม่ยกเว้นความเป็นไปได้ในการใช้ช่องโหว่เพื่อจัดระเบียบการเรียกใช้โค้ดด้วยสิทธิ์ระดับรูทแต่ความเป็นไปได้ขั้นสุดท้ายของการโจมตีดังกล่าวยังไม่ได้รับการพิจารณา

เกี่ยวกับ systemd

สำหรับผู้ที่ไม่รู้จัก Systemd ฉันสามารถบอกคุณได้ว่า นี่คือระบบเริ่มต้น linux และตัวจัดการบริการ ซึ่งรวมถึงคุณลักษณะต่างๆเช่นการเริ่มต้น daemon ตามความต้องการการบำรุงรักษาอัตโนมัติและจุดต่อเชื่อมการสนับสนุนสแน็ปช็อตและการติดตามกระบวนการโดยใช้กลุ่มควบคุม Linux

Systemd จัดเตรียมรีจิสตรีดีมอนและเครื่องมือและยูทิลิตี้อื่น ๆ เพื่อช่วยในงานการดูแลระบบทั่วไป Lennart Poettering และ Kay Sievers เขียน SystemD โดยได้รับแรงบันดาลใจจาก macOS launchd และ Upstart โดยมีเป้าหมายในการสร้างระบบที่ทันสมัยและมีพลวัต

โดยเฉพาะอย่างยิ่ง systemd มีความสามารถในการขนานเชิงรุกและตรรกะการควบคุมบริการที่อิงตามการพึ่งพาซึ่งช่วยให้บริการเริ่มต้นพร้อมกันและนำไปสู่เวลาเริ่มต้นที่เร็วขึ้น ทั้งสองด้านนี้มีอยู่ใน Upstart แต่ปรับปรุงโดย systemd

Systemd เป็นระบบบูตเริ่มต้นสำหรับการกระจาย Linux ที่สำคัญแต่มันเข้ากันได้กับสคริปต์เริ่มต้น SysV

SysVinit เป็นระบบการเตรียมใช้งานที่มาก่อน systemd และใช้วิธีการที่เรียบง่ายในการเริ่มบริการ Systemd ไม่เพียง แต่จัดการการเริ่มต้นระบบเท่านั้น แต่ยังมีทางเลือกให้กับยูทิลิตี้ที่รู้จักกันดีอื่น ๆ เช่น cron และ syslog

เกี่ยวกับช่องโหว่ systemd ใหม่

ด้วยการจัดการขนาดของข้อความที่ส่งผ่าน D-Bus ผู้โจมตีสามารถย้ายตัวชี้เกินขีด จำกัด ของหน่วยความจำที่จัดสรรสำหรับสแต็กโดยข้ามการป้องกัน "stack guard-page" ซึ่งขึ้นอยู่กับการแทนที่เพจหน่วยความจำที่ขอบที่เรียกใช้ข้อยกเว้น (page fault)

การโจมตีที่ประสบความสำเร็จแสดงให้เห็นบน Ubuntu 18.10 พร้อม systemd 239 และบน CentOS 7.6 พร้อม systemd 219

ในการแก้ปัญหาเบื้องต้นสามารถใช้การรวบรวมใน GCC ด้วยตัวเลือก "-fstack-clash-protection" ซึ่งจะใช้โดยค่าเริ่มต้นใน Fedora 28 และ 29

ควรสังเกตว่าในปี 2014 ผู้เขียนไลบรารีระบบ MUSL ได้ชี้ให้เห็นถึงปัญหาทางสถาปัตยกรรมหลักที่เป็นระบบตัวจัดการ PID1 ที่มีอัตราเงินเฟ้อมากเกินไปและตั้งคำถามถึงความเป็นไปได้ในการใช้ API ตัวควบคุมระดับ PID1 สำหรับการเชื่อมโยงกับบัสเนื่องจากเป็นเวกเตอร์ที่ร้ายแรง สำหรับการโจมตีและอาจส่งผลเสียต่อความน่าเชื่อถือของระบบทั้งหมด

ตามที่นักวิจัยด้านความปลอดภัย เผยให้เห็นช่องโหว่การเปลี่ยนแปลงตัวชี้สแต็กเป็นไปได้สำหรับเพจหน่วยความจำที่ไม่ได้ใช้เท่านั้น (unassigned) ซึ่งไม่อนุญาตให้จัดระเบียบการเรียกใช้โค้ดในบริบทของกระบวนการ PID1 แต่อนุญาตให้ผู้โจมตีเริ่มต้นการล็อก PID1 ด้วยการเปลี่ยนเคอร์เนล Linux ในภายหลังเป็นสถานะ "ตื่นตระหนก" (ในกรณีของ ตัวควบคุม PID 1 ล้มเหลวระบบทั้งหมดค้าง)

ใน systemd มีการติดตั้งตัวจัดการสัญญาณที่พยายามดักจับข้อบกพร่องของกระบวนการ PID1 (ความผิดพลาดในการแบ่งส่วน) และเริ่มต้นเชลล์สำหรับการกู้คืน

แต่เนื่องจากมีการเรียกเพจหน่วยความจำที่ไม่ซ้ำกัน (ไม่ได้ปันส่วน) ในระหว่างการโจมตีเคอร์เนลจึงไม่สามารถเรียกตัวจัดการสัญญาณนี้ได้และเพียงแค่ยุติกระบวนการด้วย PID 1 ซึ่งจะทำให้ เป็นไปไม่ได้ที่จะทำงานต่อไปและเข้าสู่สถานะ "ตื่นตระหนก" ดังนั้นจึงจำเป็นต้องรีบูตระบบ

มีแนวทางแก้ไขปัญหาอยู่แล้ว

เช่นเดียวกับปัญหาด้านความปลอดภัยใด ๆ ที่อธิบายและรายงานไปแล้วไม่สามารถทำการเผยแพร่ได้จนกว่าปัญหาจะได้รับการแก้ไขและ การอัปเดตแพทช์ช่องโหว่สำหรับ SUSE / openSUSE, Fedora ได้รับการเผยแพร่แล้วสำหรับ Ubuntu และบางส่วนสำหรับ Debian (เฉพาะ Debian Stretch เท่านั้น)
แม้ว่าปัญหาจะยังคงไม่ได้รับการแก้ไขใน RHEL