TL; DR. ในบทความนี้ เราจะมาสำรวจแผนการเสริมความแข็งแกร่งที่ทำงานนอกกรอบบน Linux ห้ารุ่นยอดนิยม เราใช้การกำหนดค่าเคอร์เนลเริ่มต้น โหลดแพ็คเกจทั้งหมด และวิเคราะห์รูปแบบการรักษาความปลอดภัยในไบนารีที่แนบมา การแจกแจงที่พิจารณาคือ OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 และ 7 รวมถึง Ubuntu 14.04, 12.04 และ 18.04 LTS

ผลลัพธ์ยืนยันว่าแม้แต่รูปแบบพื้นฐาน เช่น การซ้อนนกคีรีบูนและรหัสที่ไม่ขึ้นกับตำแหน่งก็ยังไม่มีใครนำมาใช้ สถานการณ์เลวร้ายยิ่งขึ้นสำหรับคอมไพเลอร์เมื่อต้องป้องกันช่องโหว่เช่น stack clash ซึ่งกลายเป็นที่สนใจในเดือนมกราคมหลังจากการเผยแพร่ ข้อมูลเกี่ยวกับช่องโหว่ของ systemd. แต่ไม่ใช่ทุกอย่างจะสิ้นหวังนัก ไบนารีจำนวนมากใช้วิธีการป้องกันขั้นพื้นฐาน และจำนวนไบนารี่ก็เพิ่มขึ้นจากเวอร์ชันหนึ่งไปอีกเวอร์ชันหนึ่ง

การตรวจสอบแสดงให้เห็นว่ามีการใช้วิธีการป้องกันจำนวนมากที่สุดใน Ubuntu 18.04 ที่ระบบปฏิบัติการและระดับแอปพลิเคชัน ตามมาด้วย Debian 9 ในทางกลับกัน OpenSUSE 12.4, CentOS 7 และ RHEL 7 ยังใช้แผนการป้องกันพื้นฐาน และการป้องกันการชนกันของสแต็ก ถูกใช้อย่างกว้างขวางยิ่งขึ้นด้วยชุดแพ็คเกจเริ่มต้นที่หนาแน่นกว่ามาก

การแนะนำ

เป็นการยากที่จะรับรองซอฟต์แวร์คุณภาพสูง แม้จะมีเครื่องมือขั้นสูงมากมายสำหรับการวิเคราะห์โค้ดแบบสแตติกและการวิเคราะห์รันไทม์แบบไดนามิก รวมถึงความก้าวหน้าที่สำคัญในการพัฒนาคอมไพเลอร์และภาษาการเขียนโปรแกรม แต่ซอฟต์แวร์สมัยใหม่ยังคงประสบปัญหาจากช่องโหว่ที่ผู้โจมตีมักถูกโจมตีอย่างต่อเนื่อง สถานการณ์เลวร้ายยิ่งขึ้นในระบบนิเวศที่มีรหัสเดิม ในกรณีเช่นนี้ เราไม่เพียงแต่ต้องเผชิญกับปัญหาชั่วนิรันดร์ในการค้นหาข้อผิดพลาดที่สามารถใช้ประโยชน์ได้เท่านั้น แต่เรายังถูกจำกัดด้วยเฟรมเวิร์กความเข้ากันได้แบบย้อนหลังที่เข้มงวด ซึ่งมักจะกำหนดให้เราต้องรักษาโค้ดที่มีข้อจำกัด หรือแย่กว่านั้น มีช่องโหว่หรือมีข้อผิดพลาด

นี่คือที่มาของวิธีการปกป้องหรือทำให้โปรแกรมแข็งแกร่งขึ้น เราไม่สามารถป้องกันข้อผิดพลาดบางประเภทได้ แต่เราสามารถทำให้ชีวิตของผู้โจมตียากขึ้นและแก้ไขปัญหาได้บางส่วนด้วยการป้องกันหรือป้องกัน การเอารัดเอาเปรียบ ข้อผิดพลาดเหล่านี้ การป้องกันดังกล่าวใช้ในระบบปฏิบัติการสมัยใหม่ทั้งหมด แต่วิธีการแตกต่างกันอย่างมากในด้านความซับซ้อน ประสิทธิภาพ และประสิทธิภาพ: จากนกคีรีบูนแบบสแต็กและ ASLR เพื่อการปกป้องอย่างเต็มประสิทธิภาพ CFI и ROP. ในบทความนี้ เราจะดูว่าวิธีการป้องกันใดที่ใช้ในการกำหนดค่าเริ่มต้นของ Linux ที่ได้รับความนิยมสูงสุด และตรวจสอบคุณสมบัติของไบนารีที่กระจายผ่านระบบการจัดการแพ็คเกจของแต่ละการแจกจ่าย

CVE และความปลอดภัย

เราเคยเห็นบทความที่มีชื่อว่า "แอปพลิเคชันที่มีช่องโหว่มากที่สุดแห่งปี" หรือ "ระบบปฏิบัติการที่มีช่องโหว่มากที่สุด" โดยปกติแล้วพวกเขาจะจัดทำสถิติเกี่ยวกับจำนวนบันทึกทั้งหมดเกี่ยวกับช่องโหว่เช่น CVE (ช่องโหว่และความเสี่ยงทั่วไป), ได้รับจาก ฐานข้อมูลช่องโหว่แห่งชาติ (NVD) จาก NIST และแหล่งอื่นๆ ต่อมาแอปพลิเคชันหรือระบบปฏิบัติการเหล่านี้ได้รับการจัดอันดับตามจำนวน CVE น่าเสียดายที่ CVE มีประโยชน์อย่างมากในการติดตามปัญหาและแจ้งผู้ขายและผู้ใช้ แต่พวกเขาไม่ได้พูดถึงความปลอดภัยที่แท้จริงของซอฟต์แวร์เลย

ตามตัวอย่าง ให้พิจารณาจำนวน CVE ทั้งหมดในช่วงสี่ปีที่ผ่านมาสำหรับเคอร์เนล Linux และเซิร์ฟเวอร์ที่ได้รับความนิยมสูงสุดห้ารายการ ได้แก่ Ubuntu, Debian, Red Hat Enterprise Linux และ OpenSUSE

มะเดื่อ 1

กราฟนี้บอกอะไรเรา? จำนวน CVE ที่สูงกว่าหมายความว่าการแจกจ่ายแบบหนึ่งมีความเสี่ยงมากกว่าอีกแบบหนึ่งหรือไม่? ไม่มีคำตอบ. ตัวอย่างเช่น ในบทความนี้ คุณจะเห็นว่า Debian มีกลไกความปลอดภัยที่แข็งแกร่งกว่าเมื่อเทียบกับ OpenSUSE หรือ RedHat Linux แต่ Debian มี CVE มากกว่า อย่างไรก็ตาม ไม่ได้หมายความว่าการรักษาความปลอดภัยจะอ่อนแอลงเสมอไป แม้แต่การมี CVE ก็ไม่ได้บ่งชี้ว่ามีช่องโหว่หรือไม่ ถูกเอารัดเอาเปรียบ. คะแนนความรุนแรงเป็นตัวบ่งชี้ว่าทำอย่างไร อาจ การแสวงหาผลประโยชน์จากช่องโหว่ แต่ท้ายที่สุดแล้ว ความสามารถในการแสวงหาผลประโยชน์นั้นขึ้นอยู่กับการป้องกันที่มีอยู่ในระบบที่ได้รับผลกระทบ ตลอดจนทรัพยากรและความสามารถของผู้โจมตี ยิ่งไปกว่านั้น การไม่มีรายงานของ CVE ไม่ได้บ่งบอกอะไรเกี่ยวกับรายงานอื่นๆ เลย ไม่ได้ลงทะเบียนหรือไม่ทราบ ช่องโหว่ ความแตกต่างใน CVE อาจเนื่องมาจากปัจจัยอื่นนอกเหนือจากคุณภาพของซอฟต์แวร์ รวมถึงทรัพยากรที่จัดสรรให้กับการทดสอบหรือขนาดของฐานผู้ใช้ ในตัวอย่างของเรา จำนวน CVE ที่สูงกว่าของ Debian อาจบ่งชี้ว่า Debian จัดส่งแพ็คเกจซอฟต์แวร์มากขึ้น

แน่นอนว่าระบบ CVE ให้ข้อมูลที่เป็นประโยชน์ซึ่งช่วยให้คุณสามารถสร้างการป้องกันที่เหมาะสมได้ ยิ่งเราเข้าใจสาเหตุของความล้มเหลวของโปรแกรมได้ดีเพียงใด การระบุวิธีการใช้ประโยชน์และพัฒนากลไกที่เหมาะสมก็จะยิ่งง่ายขึ้นเท่านั้น การตรวจจับและการตอบสนอง. ในรูป 2 แสดงหมวดหมู่ของช่องโหว่สำหรับการแจกแจงทั้งหมดในช่วงสี่ปีที่ผ่านมา (แหล่ง). เป็นที่ชัดเจนว่า CVE ส่วนใหญ่จัดอยู่ในหมวดหมู่ต่อไปนี้: การปฏิเสธการบริการ (DoS), การเรียกใช้โค้ด, การล้น, หน่วยความจำเสียหาย, ข้อมูลรั่วไหล (การกรอง) และการเพิ่มระดับสิทธิ์ แม้ว่า CVE จำนวนมากจะถูกนับหลายครั้งในหมวดหมู่ต่างๆ แต่โดยทั่วไปแล้วปัญหาเดียวกันยังคงมีอยู่ปีแล้วปีเล่า ในส่วนถัดไปของบทความ เราจะประเมินการใช้แผนการป้องกันต่างๆ เพื่อป้องกันการหาประโยชน์จากช่องโหว่เหล่านี้

มะเดื่อ 2

งาน

ในบทความนี้เราตั้งใจที่จะตอบคำถามต่อไปนี้:

• ความปลอดภัยของลีนุกซ์รุ่นต่างๆ คืออะไร? กลไกการป้องกันที่มีอยู่ในเคอร์เนลและแอปพลิเคชันพื้นที่ผู้ใช้มีอะไรบ้าง
• การนำกลไกการรักษาความปลอดภัยไปใช้มีการเปลี่ยนแปลงอย่างไรเมื่อเวลาผ่านไปในการกระจาย?
• การพึ่งพาโดยเฉลี่ยของแพ็คเกจและไลบรารีสำหรับการแจกจ่ายแต่ละครั้งคือเท่าใด
• มีการป้องกันอะไรบ้างสำหรับแต่ละไบนารี?

การเลือกการกระจาย

ปรากฎว่าเป็นการยากที่จะค้นหาสถิติที่แม่นยำเกี่ยวกับการติดตั้งการแจกจ่ายเนื่องจากในกรณีส่วนใหญ่จำนวนการดาวน์โหลดไม่ได้ระบุจำนวนการติดตั้งจริง อย่างไรก็ตาม ตัวแปร Unix ประกอบขึ้นเป็นระบบเซิร์ฟเวอร์ส่วนใหญ่ (บนเว็บเซิร์ฟเวอร์ 69,2% โดย สถิติ W3techs และแหล่งข้อมูลอื่นๆ) และมีส่วนแบ่งเพิ่มขึ้นอย่างต่อเนื่อง ดังนั้น สำหรับการวิจัยของเรา เรามุ่งเน้นไปที่การแจกแจงที่มีให้ทันทีบนแพลตฟอร์ม Google Cloud. โดยเฉพาะอย่างยิ่ง เราเลือกระบบปฏิบัติการต่อไปนี้:

การจำหน่าย/เวอร์ชัน
แกนกลาง
สร้าง

OpenSUSE 12.4
4.12.14-95.3-ค่าเริ่มต้น
#1 SMP วันพุธที่ 5 ธันวาคม 06:00:48 UTC 2018 (63a8d29)

เดเบียน 9 (ยืด)
4.9.0-8-amd64
#1 SMP เดเบียน 4.9.130-2 (2018-10-27)

6.10 CentOS
2.6.32-754.10.1.el6.x86_64
#1 SMP วันอังคารที่ 15 ม.ค. 17:07:28 UTC 2019

7 CentOS
3.10.0-957.5.1.el7.x86_64
#1 SMP วันศุกร์ที่ 1 กุมภาพันธ์ เวลา 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (ซันติอาโก)
2.6.32-754.9.1.el6.x86_64
#1 SMP วันพุธที่ 21 พ.ย. 15:08:21 น. EST 2018

Red Hat Enterprise Linux Server 7.6 (ไมโป)
3.10.0-957.1.3.el7.x86_64
#1 SMP พฤ. 15 พ.ย. 17:36:42 UTC 2018

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-ทั่วไป

#166~14.04.1-Ubuntu SMP วันเสาร์ที่ 17 พฤศจิกายน 01:52:43 UTC 20…

อูบุนตู 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP วันศุกร์ที่ 7 ธันวาคม 09:59:47 UTC 2018

Ubuntu 18.04 (ไบโอนิคบีเวอร์)
4.15.0–1026-gcp
#27-Ubuntu SMP พฤหัสบดีที่ 6 ธันวาคม 18:27:01 UTC 2018

1 ตาราง

การวิเคราะห์

มาศึกษาการกำหนดค่าเคอร์เนลเริ่มต้นตลอดจนคุณสมบัติของแพ็คเกจที่มีให้ผ่านตัวจัดการแพ็คเกจของการแจกจ่ายแต่ละครั้งแบบแกะกล่อง ดังนั้นเราจึงพิจารณาเฉพาะแพ็คเกจจากมิเรอร์เริ่มต้นของการแจกจ่ายแต่ละครั้ง โดยไม่สนใจแพ็คเกจจากที่เก็บข้อมูลที่ไม่เสถียร (เช่น มิเรอร์ 'การทดสอบ' ของ Debian) และแพ็คเกจของบุคคลที่สาม (เช่น แพ็คเกจ Nvidia จากมิเรอร์มาตรฐาน) นอกจากนี้ เราไม่พิจารณาการคอมไพล์เคอร์เนลแบบกำหนดเองหรือการกำหนดค่าที่เสริมความปลอดภัย

การวิเคราะห์การกำหนดค่าเคอร์เนล

เราใช้สคริปต์การวิเคราะห์ตาม ตัวตรวจสอบ kconfig ฟรี. ลองดูที่พารามิเตอร์การป้องกันแบบสำเร็จรูปของการแจกแจงที่มีชื่อและเปรียบเทียบกับรายการจาก โครงการป้องกันตนเองแกนกลาง (กสปป.) สำหรับแต่ละตัวเลือกการกำหนดค่า ตารางที่ 2 อธิบายการตั้งค่าที่ต้องการ: ช่องทำเครื่องหมายมีไว้สำหรับการกระจายที่สอดคล้องกับคำแนะนำ KSSP (ดูคำอธิบายข้อกำหนดต่อไปนี้) ที่นี่; ในบทความต่อๆ ไป เราจะอธิบายว่ามีวิธีการรักษาความปลอดภัยเหล่านี้เกิดขึ้นได้กี่วิธี และจะแฮ็กระบบได้อย่างไรหากไม่มีอยู่)

โดยทั่วไปแล้ว เมล็ดพืชใหม่จะมีการตั้งค่าที่เข้มงวดมากขึ้นตั้งแต่แกะกล่อง ตัวอย่างเช่น CentOS 6.10 และ RHEL 6.10 บนเคอร์เนล 2.6.32 ขาดคุณสมบัติที่สำคัญส่วนใหญ่ที่ใช้ในเคอร์เนลรุ่นใหม่ เช่น สแมปสิทธิ์ RWX ที่เข้มงวด การสุ่มที่อยู่ หรือการป้องกัน copy2usr ควรสังเกตว่าตัวเลือกการกำหนดค่าจำนวนมากในตารางไม่มีอยู่ในเคอร์เนลเวอร์ชันเก่าและไม่สามารถใช้ได้ในความเป็นจริง - นี่ยังคงระบุไว้ในตารางว่าขาดการป้องกันที่เหมาะสม ในทำนองเดียวกัน หากไม่มีตัวเลือกการกำหนดค่าในเวอร์ชันที่กำหนด และการรักษาความปลอดภัยจำเป็นต้องปิดใช้งานตัวเลือกนั้น ก็ถือเป็นการกำหนดค่าที่สมเหตุสมผล

อีกประเด็นที่ควรพิจารณาเมื่อตีความผลลัพธ์: การกำหนดค่าเคอร์เนลบางอย่างที่เพิ่มพื้นผิวการโจมตีสามารถใช้เพื่อรักษาความปลอดภัยได้เช่นกัน ตัวอย่างดังกล่าว ได้แก่ uprobes และ kprobes โมดูลเคอร์เนล และ BPF/eBPF คำแนะนำของเราคือการใช้กลไกข้างต้นเพื่อให้การป้องกันที่แท้จริง เนื่องจากกลไกเหล่านี้ใช้งานได้อย่างง่ายดาย และการแสวงหาประโยชน์จากกลไกเหล่านี้ถือว่าผู้ไม่ประสงค์ดีได้ตั้งหลักในระบบแล้ว แต่หากเปิดใช้งานตัวเลือกเหล่านี้ ผู้ดูแลระบบจะต้องตรวจสอบการละเมิดอย่างจริงจัง

เมื่อดูเพิ่มเติมที่รายการในตารางที่ 2 เราพบว่าเคอร์เนลสมัยใหม่มีตัวเลือกมากมายสำหรับการป้องกันการหาประโยชน์จากช่องโหว่ เช่น ข้อมูลรั่วไหล และสแต็ก/ฮีปล้น อย่างไรก็ตาม เราสังเกตเห็นว่าแม้แต่การกระจายที่ได้รับความนิยมล่าสุดก็ยังไม่ได้ใช้การป้องกันที่ซับซ้อนกว่านี้ (เช่น ด้วยแพตช์ ความปลอดภัยสูง) หรือการป้องกันสมัยใหม่จากการโจมตีการใช้โค้ดซ้ำ (เช่น การรวมกันของการสุ่มด้วยโครงร่างเช่น R^X สำหรับโค้ด). ที่แย่ไปกว่านั้น แม้แต่การป้องกันขั้นสูงเหล่านี้ก็ยังไม่สามารถป้องกันการโจมตีได้เต็มรูปแบบ ดังนั้นจึงเป็นเรื่องสำคัญสำหรับผู้ดูแลระบบที่จะต้องเสริมการกำหนดค่าอัจฉริยะด้วยโซลูชันที่ให้การตรวจจับและป้องกันการใช้ประโยชน์จากรันไทม์

การวิเคราะห์แอปพลิเคชัน

ไม่น่าแปลกใจเลยที่การแจกแจงที่แตกต่างกันจะมีลักษณะแพ็คเกจ ตัวเลือกการคอมไพล์ การพึ่งพาไลบรารี ฯลฯ ที่แตกต่างกัน มีความแตกต่างอยู่แม้กระทั่งสำหรับ ที่เกี่ยวข้อง การแจกแจงและแพ็คเกจที่มีการขึ้นต่อกันจำนวนเล็กน้อย (เช่น coreutils บน Ubuntu หรือ Debian) เพื่อประเมินความแตกต่าง เราได้ดาวน์โหลดแพ็คเกจที่มีอยู่ทั้งหมด แยกเนื้อหา และวิเคราะห์ไบนารีและการขึ้นต่อกัน สำหรับแต่ละแพ็คเกจ เราได้ติดตามแพ็คเกจอื่นๆ ที่ต้องพึ่งพา และสำหรับไบนารีแต่ละรายการ เราได้ติดตามการขึ้นต่อกันของแพ็คเกจนั้น ในส่วนนี้เราจะสรุปข้อสรุปโดยย่อ

การกระจาย

โดยรวมแล้ว เราดาวน์โหลดแพ็คเกจ 361 แพ็คเกจสำหรับการแจกจ่ายทั้งหมด โดยแยกเฉพาะแพ็คเกจจากมิเรอร์เริ่มต้นเท่านั้น เราละเว้นแพ็คเกจที่ไม่มีโปรแกรมปฏิบัติการของ ELF เช่น แหล่งที่มา แบบอักษร ฯลฯ หลังจากการกรอง เหลือแพ็คเกจ 556 แพ็คเกจ ซึ่งมีไบนารีทั้งหมด 129 รายการ การกระจายแพ็คเกจและไฟล์ระหว่างการแจกแจงจะแสดงในรูป 569.

มะเดื่อ 3

คุณอาจสังเกตเห็นว่ายิ่งการกระจายมีความทันสมัยมากขึ้นเท่าใด แพ็คเกจและไบนารีก็ยิ่งมีมากขึ้นเท่านั้น ซึ่งก็สมเหตุสมผล อย่างไรก็ตาม แพ็คเกจ Ubuntu และ Debian มีไบนารีจำนวนมาก (ทั้งไฟล์ปฏิบัติการและโมดูลไดนามิกและไลบรารี) มากกว่า CentOS, SUSE และ RHEL ซึ่งอาจส่งผลกระทบต่อพื้นผิวการโจมตีของ Ubuntu และ Debian (ควรสังเกตว่าตัวเลขสะท้อนถึงไบนารีทั้งหมดของทุกเวอร์ชัน package นั่นคือไฟล์บางไฟล์จะถูกวิเคราะห์หลายครั้ง) นี่เป็นสิ่งสำคัญอย่างยิ่งเมื่อคุณพิจารณาถึงการขึ้นต่อกันระหว่างแพ็คเกจ ดังนั้น ช่องโหว่ในไบนารี่แพ็คเกจเดียวอาจส่งผลกระทบต่อหลายส่วนของระบบนิเวศ เช่นเดียวกับไลบรารีที่มีช่องโหว่สามารถส่งผลกระทบต่อไบนารีทั้งหมดที่นำเข้ามัน สำหรับจุดเริ่มต้น มาดูการกระจายจำนวนการขึ้นต่อกันระหว่างแพ็คเกจในระบบปฏิบัติการที่แตกต่างกัน:

มะเดื่อ 4

ในการแจกแจงเกือบทั้งหมด 60% ของแพ็คเกจมีการขึ้นต่อกันอย่างน้อย 10 รายการ นอกจากนี้ บางแพ็คเกจยังมีจำนวนการขึ้นต่อกันที่มากกว่าอย่างเห็นได้ชัด (มากกว่า 100) เช่นเดียวกับการขึ้นต่อกันของแพ็คเกจแบบย้อนกลับ: ตามที่คาดไว้ แพ็คเกจบางส่วนจะถูกใช้โดยแพ็คเกจอื่น ๆ จำนวนมากในการแจกจ่าย ดังนั้นช่องโหว่ในแพ็คเกจบางตัวที่เลือกจึงมีความเสี่ยงสูง ตามตัวอย่าง ตารางต่อไปนี้แสดงรายการแพ็คเกจ 20 รายการที่มีจำนวนการขึ้นต่อกันแบบย้อนกลับสูงสุดใน SLES, Centos 7, Debian 9 และ Ubuntu 18.04 (แต่ละเซลล์ระบุแพ็คเกจและจำนวนการขึ้นต่อกันแบบย้อนกลับ)

3 ตาราง

ความจริงที่น่าสนใจ. แม้ว่าระบบปฏิบัติการทั้งหมดที่วิเคราะห์จะถูกสร้างขึ้นสำหรับสถาปัตยกรรม x86_64 และแพ็คเกจส่วนใหญ่มีสถาปัตยกรรมที่กำหนดเป็น x86_64 และ x86 แต่แพ็คเกจมักจะมีไบนารีสำหรับสถาปัตยกรรมอื่นๆ ดังแสดงในรูปที่ 5 XNUMX.

มะเดื่อ 5

ในส่วนถัดไป เราจะเจาะลึกถึงลักษณะของไบนารีที่วิเคราะห์

สถิติการป้องกันไฟล์ไบนารี

อย่างน้อยที่สุด คุณจะต้องสำรวจชุดตัวเลือกความปลอดภัยขั้นพื้นฐานสำหรับไบนารีที่มีอยู่ของคุณ Linux หลายรุ่นมาพร้อมกับสคริปต์ที่ทำการตรวจสอบดังกล่าว ตัวอย่างเช่น Debian/Ubuntu มีสคริปต์ดังกล่าว นี่คือตัวอย่างผลงานของเขา:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

สคริปต์ตรวจสอบห้า ฟังก์ชั่นการป้องกัน:

• Position Independent Executable (PIE): ระบุว่าส่วนข้อความของโปรแกรมสามารถย้ายไปยังหน่วยความจำเพื่อให้เกิดการสุ่มได้หรือไม่ หากเปิดใช้งาน ASLR ในเคอร์เนล
• Stack Protected: เปิดใช้งาน Stack Canaries เพื่อป้องกันการโจมตีจากการชนกันของ Stack หรือไม่
• Fortify Source: ฟังก์ชันที่ไม่ปลอดภัย (เช่น strcpy) จะถูกแทนที่ด้วยฟังก์ชันที่มีความปลอดภัยมากกว่าหรือไม่ และการเรียกที่ตรวจสอบขณะรันไทม์จะถูกแทนที่ด้วยฟังก์ชันที่ยังไม่ได้ตรวจสอบ (เช่น memcpy แทนที่จะเป็น __memcpy_chk)
• การย้ายตำแหน่งแบบอ่านอย่างเดียว (RELRO): ไม่ว่ารายการตารางการย้ายตำแหน่งจะถูกทำเครื่องหมายเป็นแบบอ่านอย่างเดียวหรือไม่ หากรายการเหล่านั้นถูกทริกเกอร์ก่อนที่การดำเนินการจะเริ่มขึ้น
• การเชื่อมโยงทันที: ไม่ว่ารันไทม์ลิงเกอร์จะอนุญาตการเคลื่อนไหวทั้งหมดก่อนที่โปรแกรมจะเริ่มต้นหรือไม่ (ซึ่งเทียบเท่ากับ RELRO แบบเต็ม)

กลไกข้างต้นเพียงพอหรือไม่? น่าเสียดายที่ไม่มี มีหลายวิธีที่ทราบกันดีว่าสามารถเลี่ยงการป้องกันข้างต้นทั้งหมดได้ แต่ยิ่งการป้องกันมีความแข็งแกร่งเท่าใด ผู้โจมตีก็จะยิ่งมีเกณฑ์สูงตามไปด้วย ตัวอย่างเช่น, วิธีการบายพาส RELRO ยากกว่าที่จะใช้หาก PIE และการเชื่อมโยงทันทีมีผลบังคับใช้ ในทำนองเดียวกัน ASLR แบบเต็มจำเป็นต้องมีการทำงานเพิ่มเติมเพื่อสร้างช่องโหว่ที่ใช้งานได้ อย่างไรก็ตาม ผู้โจมตีที่มีความซับซ้อนได้เตรียมพร้อมที่จะปฏิบัติตามการป้องกันดังกล่าวแล้ว การไม่มีพวกเขาจะช่วยเร่งการแฮ็กให้เร็วขึ้น ดังนั้นจึงจำเป็นอย่างยิ่งที่จะต้องถือว่ามาตรการเหล่านี้มีความจำเป็น ขั้นต่ำ.

เราต้องการศึกษาว่าไฟล์ไบนารีจำนวนเท่าใดในการแจกแจงที่เป็นปัญหาได้รับการปกป้องโดยวิธีเหล่านี้และวิธีอื่นอีกสามวิธี:

• บิตที่ไม่สามารถใช้งานได้ (NX) ป้องกันการดำเนินการในภูมิภาคใดๆ ที่ไม่ควรเรียกใช้งาน เช่น สแต็กฮีป เป็นต้น
• ราพาธ/รันพาธ หมายถึงเส้นทางการดำเนินการที่ใช้โดยตัวโหลดแบบไดนามิกเพื่อค้นหาไลบรารีที่ตรงกัน อันแรกก็คือ ภาคบังคับ สำหรับระบบสมัยใหม่: การไม่มีระบบทำให้ผู้โจมตีสามารถเขียนเพย์โหลดลงในหน่วยความจำโดยพลการและดำเนินการตามที่เป็นอยู่ ประการที่สอง การกำหนดค่าพาธการดำเนินการที่ไม่ถูกต้องจะช่วยในการแนะนำโค้ดที่ไม่น่าเชื่อถือ ซึ่งอาจนำไปสู่ปัญหาหลายประการ (เช่น การเพิ่มสิทธิพิเศษและ ปัญหาอื่นๆ).
• การป้องกันการชนกันของสแต็กให้การป้องกันการโจมตีที่ทำให้สแต็กซ้อนทับพื้นที่หน่วยความจำอื่นๆ (เช่น ฮีป) เมื่อพิจารณาถึงการละเมิดการหาประโยชน์ล่าสุด ช่องโหว่การชนกันของฮีป systemdเรารู้สึกว่าเป็นการเหมาะสมที่จะรวมกลไกนี้ไว้ในชุดข้อมูลของเรา

เอาล่ะ เพื่อเป็นการไม่ให้เสียเวลา มาดูตัวเลขกันดีกว่า ตารางที่ 4 และ 5 ประกอบด้วยบทสรุปการวิเคราะห์ไฟล์ปฏิบัติการและไลบรารีของการแจกแจงต่างๆ ตามลำดับ

• อย่างที่คุณเห็น การป้องกัน NX นั้นมีการใช้งานทุกที่ โดยมีข้อยกเว้นที่หายาก โดยเฉพาะอย่างยิ่ง เราสามารถสังเกตการใช้งานที่ลดลงเล็กน้อยใน Ubuntu และ Debian เมื่อเทียบกับ CentOS, RHEL และ OpenSUSE
• นกคีรีบูนกองขาดหายไปในหลายแห่ง โดยเฉพาะอย่างยิ่งการกระจายพันธุ์ที่มีเมล็ดเก่า ความคืบหน้าบางอย่างปรากฏให้เห็นในการกระจายล่าสุดของ Centos, RHEL, Debian และ Ubuntu
• ยกเว้น Debian และ Ubuntu 18.04 การแจกแจงส่วนใหญ่มีการรองรับ PIE ที่ไม่ดี
• การป้องกันการชนกันของสแต็กนั้นอ่อนแอใน OpenSUSE, Centos 7 และ RHEL 7 และแทบไม่มีในผู้อื่น
• การแจกแจงทั้งหมดที่มีเคอร์เนลสมัยใหม่รองรับ RELRO บ้าง โดยที่ Ubuntu 18.04 เป็นผู้นำและ Debian มาเป็นอันดับสอง

ดังที่ได้กล่าวไปแล้ว หน่วยเมตริกในตารางนี้เป็นค่าเฉลี่ยสำหรับไฟล์ไบนารีทุกเวอร์ชัน หากคุณดูเฉพาะไฟล์เวอร์ชันล่าสุด ตัวเลขจะแตกต่างออกไป (เช่น ดูที่ ความคืบหน้าของ Debian ด้วยการใช้ PIE). นอกจากนี้ การแจกแจงส่วนใหญ่มักจะทดสอบความปลอดภัยของฟังก์ชันบางอย่างในไบนารี่เมื่อคำนวณสถิติเท่านั้น แต่การวิเคราะห์ของเราแสดงเปอร์เซ็นต์ที่แท้จริงของฟังก์ชันที่แข็งตัว ดังนั้น หากฟังก์ชัน 5 จาก 50 รายการได้รับการป้องกันในรูปแบบไบนารี่ เราจะให้คะแนน 0,1 ซึ่งเท่ากับ 10% ของฟังก์ชันที่กำลังเสริมความแข็งแกร่ง

ตารางที่ 4. คุณลักษณะด้านความปลอดภัยสำหรับไฟล์ปฏิบัติการที่แสดงในรูปที่ 3 XNUMX (การใช้งานฟังก์ชันที่เกี่ยวข้องเป็นเปอร์เซ็นต์ของจำนวนไฟล์ปฏิบัติการทั้งหมด)

ตารางที่ 5. คุณลักษณะด้านความปลอดภัยสำหรับไลบรารีที่แสดงในรูปที่ 3 XNUMX (การใช้งานฟังก์ชันที่เกี่ยวข้องเป็นเปอร์เซ็นต์ของจำนวนห้องสมุดทั้งหมด)

แล้วมีความคืบหน้ามั้ย? มีแน่นอน: สิ่งนี้สามารถเห็นได้จากสถิติของการแจกแจงรายบุคคล (เช่น debian) รวมถึงจากตารางด้านบนด้วย ดังตัวอย่างในรูป รูปที่ 6 แสดงการใช้งานกลไกการป้องกันในการกระจาย Ubuntu LTS 5 สามครั้งติดต่อกัน (เราได้ละเว้นสถิติการป้องกันการชนกันของสแต็ก) เราสังเกตเห็นว่าจากเวอร์ชันหนึ่งไปอีกเวอร์ชันหนึ่ง ไฟล์ต่างๆ รองรับนกคีรีบูนแบบกองซ้อนมากขึ้นเรื่อยๆ และยังมีไบนารีจำนวนมากขึ้นเรื่อยๆ ที่มาพร้อมการป้องกัน RELRO เต็มรูปแบบ

มะเดื่อ 6

น่าเสียดายที่ไฟล์ปฏิบัติการจำนวนหนึ่งในการแจกจ่ายที่แตกต่างกันยังไม่มีการป้องกันใดๆ ข้างต้น ตัวอย่างเช่น เมื่อดูที่ Ubuntu 18.04 คุณจะสังเกตเห็นไบนารี ngetty (การแทนที่แบบ getty) เช่นเดียวกับ mksh และ lksh เชลล์ ตัวแปล picolisp แพ็คเกจ nvidia-cuda-toolkit (แพ็คเกจยอดนิยมสำหรับแอปพลิเคชันที่เร่งด้วย GPU เช่น กรอบงานการเรียนรู้ของเครื่อง) และ klibc -utils ในทำนองเดียวกัน ไบนารี mandos-client (เครื่องมือการดูแลระบบที่อนุญาตให้คุณรีบูตเครื่องโดยอัตโนมัติด้วยระบบไฟล์ที่เข้ารหัส) เช่นเดียวกับ rsh-redone-client (การนำ rsh และ rlogin ไปใช้ใหม่) จัดส่งโดยไม่มีการป้องกัน NX แม้ว่าพวกเขาจะมีสิทธิ์ SUID : (นอกจากนี้ ไบนารี suid จำนวนมากยังขาดการป้องกันขั้นพื้นฐาน เช่น นกคีรีบูนแบบสแต็ก (เช่น ไบนารี Xorg.wrap จากแพ็คเกจ Xorg)

สรุปและข้อสังเกตสรุป

ในบทความนี้ เราได้เน้นย้ำถึงคุณลักษณะด้านความปลอดภัยหลายประการของลีนุกซ์รุ่นใหม่ การวิเคราะห์แสดงให้เห็นว่าการกระจาย Ubuntu LTS ล่าสุด (18.04) ใช้งานโดยเฉลี่ยแล้ว ระบบปฏิบัติการและการป้องกันระดับแอปพลิเคชันที่แข็งแกร่งที่สุดระหว่างการกระจายที่มีเคอร์เนลที่ค่อนข้างใหม่ เช่น Ubuntu 14.04, 12.04 และ Debian 9 อย่างไรก็ตาม การกระจายที่ตรวจสอบ CentOS, RHEL และ OpenSUSE ในชุดของเราตามค่าเริ่มต้นจะสร้างชุดแพ็คเกจที่หนาแน่นขึ้น และในเวอร์ชันล่าสุด (CentOS และ RHEL) จะมีเปอร์เซ็นต์การป้องกันการชนกันของสแต็กที่สูงกว่าเมื่อเปรียบเทียบกับคู่แข่งที่ใช้ Debian (Debian และ Ubuntu) เมื่อเปรียบเทียบเวอร์ชัน CentOS และ RedHat เราสังเกตเห็นการปรับปรุงครั้งใหญ่ในการใช้งาน stack canaries และ RELRO จากเวอร์ชัน 6 ถึง 7 แต่โดยเฉลี่ยแล้ว CentOS มีฟีเจอร์ที่ใช้งานมากกว่า RHEL โดยทั่วไปแล้ว การแจกแจงทั้งหมดควรให้ความสนใจเป็นพิเศษกับการป้องกัน PIE ซึ่งยกเว้น Debian 9 และ Ubuntu 18.04 นั้นถูกนำไปใช้น้อยกว่า 10% ของไบนารีในชุดข้อมูลของเรา

สุดท้ายนี้ ควรสังเกตว่าแม้ว่าเราจะดำเนินการวิจัยด้วยตนเอง แต่ก็มีเครื่องมือรักษาความปลอดภัยมากมาย (เช่น Lynis, เสือ, ฮับ​​เบิล) ซึ่งทำการวิเคราะห์และช่วยหลีกเลี่ยงการกำหนดค่าที่ไม่ปลอดภัย น่าเสียดายที่การป้องกันที่แข็งแกร่งในการกำหนดค่าที่สมเหตุสมผลไม่ได้รับประกันว่าจะไม่มีช่องโหว่ นั่นเป็นเหตุผลที่เราเชื่อมั่นว่าการรับรองเป็นสิ่งสำคัญ การตรวจสอบและป้องกันการโจมตีที่เชื่อถือได้แบบเรียลไทม์โดยเน้นรูปแบบการแสวงหาประโยชน์และการป้องกัน

ที่มา: will.com