TL; DR. ამ სტატიაში ჩვენ განვიხილავთ გამკვრივების სქემებს, რომლებიც სრულყოფილად მუშაობს Linux-ის ხუთ პოპულარულ დისტრიბუციაზე. თითოეულისთვის ავიღეთ ბირთვის ნაგულისხმევი კონფიგურაცია, ჩავტვირთეთ ყველა პაკეტი და გავაანალიზეთ უსაფრთხოების სქემები თანდართულ ბინარებში. განხილული დისტრიბუციებია OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 და 7, ასევე Ubuntu 14.04, 12.04 და 18.04 LTS.

შედეგები ადასტურებს, რომ ისეთი ძირითადი სქემებიც კი, როგორიცაა კანარის დაწყობა და თანამდებობიდან დამოუკიდებელი კოდი, ჯერ არ არის მიღებული ყველას მიერ. სიტუაცია კიდევ უფრო უარესია შემდგენლებისთვის, როდესაც საქმე ეხება დაუცველობისგან დაცვას, როგორიცაა სტეკის შეჯახება, რომელიც ყურადღების ცენტრში მოექცა იანვარში გამოქვეყნების შემდეგ. ინფორმაცია სისტემური დაუცველობის შესახებ. მაგრამ ყველაფერი ასე უიმედო არ არის. ბინარების მნიშვნელოვანი რაოდენობა ახორციელებს დაცვის ძირითად მეთოდებს და მათი რიცხვი იზრდება ვერსიიდან ვერსიამდე.

მიმოხილვამ აჩვენა, რომ დაცვის მეთოდების უდიდესი რაოდენობა დანერგილია Ubuntu 18.04-ში OS და აპლიკაციის დონეზე, რასაც მოჰყვება Debian 9. მეორეს მხრივ, OpenSUSE 12.4, CentOS 7 და RHEL 7 ასევე ახორციელებენ დაცვის ძირითად სქემებს და დატის შეჯახებისგან დაცვას. გამოიყენება კიდევ უფრო ფართოდ ნაგულისხმევი პაკეტების ბევრად უფრო მკვრივი ნაკრებით.

შესავალი

ძნელია უზრუნველყოს მაღალი ხარისხის პროგრამული უზრუნველყოფა. მიუხედავად სტატიკური კოდის ანალიზისა და დინამიური გაშვების ანალიზისთვის მოწინავე ხელსაწყოების დიდი რაოდენობისა, ასევე შემდგენლებისა და პროგრამირების ენების შემუშავებაში მნიშვნელოვანი პროგრესის მიუხედავად, თანამედროვე პროგრამული უზრუნველყოფა კვლავ განიცდის დაუცველობას, რომელსაც მუდმივად იყენებენ თავდამსხმელები. მდგომარეობა კიდევ უფრო უარესია ეკოსისტემებში, რომლებიც შეიცავს მემკვიდრეობით კოდს. ასეთ შემთხვევებში, ჩვენ არა მხოლოდ ვაწყდებით შესაძლო ექსპლუატირებადი შეცდომების პოვნის მარადიულ პრობლემას, არამედ შეზღუდულნი ვართ მკაცრი უკან თავსებადობის ჩარჩოებით, რომლებიც ხშირად გვთხოვენ შევინარჩუნოთ შეზღუდული, ან კიდევ უფრო უარესი, დაუცველი ან ბაგი კოდი.

სწორედ აქ მოქმედებს პროგრამების დაცვის ან გამკვრივების მეთოდები. ჩვენ არ შეგვიძლია თავიდან ავიცილოთ ზოგიერთი სახის შეცდომები, მაგრამ შეგვიძლია გავართულოთ თავდამსხმელის ცხოვრება და ნაწილობრივ მოვაგვაროთ პრობლემა პრევენციის ან პრევენციის გზით. ექსპლუატაცია ეს შეცდომები. ასეთი დაცვა გამოიყენება ყველა თანამედროვე ოპერაციულ სისტემაში, მაგრამ მეთოდები მნიშვნელოვნად განსხვავდება სირთულის, ეფექტურობისა და ეფექტურობის მიხედვით: დასტა კანარისგან და ASLR სრული დაცვისთვის CFI и R.O.P.. ამ სტატიაში განვიხილავთ, თუ რა დაცვის მეთოდებს იყენებენ Linux-ის ყველაზე პოპულარულ დისტრიბუციაში ნაგულისხმევი კონფიგურაციაში და ასევე განვიხილავთ ბინარების თვისებებს, რომლებიც ნაწილდება თითოეული განაწილების პაკეტების მართვის სისტემებით.

CVE და უსაფრთხოება

ჩვენ ყველას გვინახავს სტატიები სათაურებით, როგორიცაა „წლის ყველაზე დაუცველი აპლიკაციები“ ან „ყველაზე დაუცველი ოპერაციული სისტემები“. ჩვეულებრივ, ისინი აწვდიან სტატისტიკას მოწყვლადობის შესახებ ჩანაწერების საერთო რაოდენობის შესახებ, როგორიცაა CVE (საერთო დაუცველობა და ექსპოზიციები), მიღებული დაუცველობის ეროვნული მონაცემთა ბაზა (NVD) საწყისი NIST და სხვა წყაროები. შემდგომში, ეს აპლიკაციები ან OS ფასდება CVE-ების რაოდენობის მიხედვით. სამწუხაროდ, მიუხედავად იმისა, რომ CVE ძალიან სასარგებლოა საკითხების თვალყურის დევნებისთვის და მომწოდებლებისა და მომხმარებლების ინფორმირებისთვის, ისინი ცოტას ამბობენ პროგრამული უზრუნველყოფის რეალურ უსაფრთხოებაზე.

მაგალითად, განვიხილოთ CVE-ების საერთო რაოდენობა ბოლო ოთხი წლის განმავლობაში Linux-ის ბირთვისთვის და ხუთი ყველაზე პოპულარული სერვერის დისტრიბუციისთვის, კერძოდ, Ubuntu, Debian, Red Hat Enterprise Linux და OpenSUSE.

Fig. 1

რას გვეუბნება ეს გრაფიკი? ნიშნავს თუ არა CVE-ების უფრო მეტი რაოდენობა, რომ ერთი განაწილება უფრო დაუცველია, ვიდრე მეორე? Პასუხის გარეშე. მაგალითად, ამ სტატიაში ნახავთ, რომ Debian-ს აქვს უფრო ძლიერი უსაფრთხოების მექანიზმები, მაგალითად, OpenSUSE ან RedHat Linux-თან შედარებით, და მაინც Debian-ს აქვს მეტი CVE. თუმცა, ისინი სულაც არ ნიშნავს დასუსტებულ უსაფრთხოებას: CVE-ის არსებობაც კი არ მიუთითებს, არის თუ არა დაუცველობა. ექსპლუატირებული. სიმძიმის ქულები მიუთითებს იმაზე, თუ როგორ ალბათ მოწყვლადობის ექსპლუატაცია, მაგრამ საბოლოო ჯამში ექსპლუატაცია დიდწილად დამოკიდებულია დაზარალებულ სისტემებში არსებულ დაცვაზე და თავდამსხმელთა რესურსებსა და შესაძლებლობებზე. უფრო მეტიც, CVE ანგარიშების არარსებობა არაფერს ამბობს სხვებზე დაურეგისტრირებელი ან უცნობი სისუსტეები. CVE-ში განსხვავება შეიძლება გამოწვეული იყოს პროგრამული უზრუნველყოფის ხარისხის გარდა სხვა ფაქტორებით, მათ შორის ტესტირებისთვის გამოყოფილი რესურსებით ან მომხმარებლის ბაზის ზომით. ჩვენს მაგალითში, Debian-ის CVE-ების უფრო მეტი რაოდენობა შეიძლება უბრალოდ მიუთითებდეს, რომ Debian აგზავნის უფრო მეტ პროგრამულ პაკეტს.

რა თქმა უნდა, CVE სისტემა გვაწვდის სასარგებლო ინფორმაციას, რომელიც საშუალებას გაძლევთ შექმნათ შესაბამისი დაცვა. რაც უფრო კარგად გვესმის პროგრამის წარუმატებლობის მიზეზები, მით უფრო ადვილია ექსპლუატაციის შესაძლო მეთოდების იდენტიფიცირება და შესაბამისი მექანიზმების შემუშავება. გამოვლენა და რეაგირება. ნახ. 2 აჩვენებს დაუცველობის კატეგორიებს ყველა განაწილებისთვის ბოლო ოთხი წლის განმავლობაში (წყარო). მაშინვე ნათელია, რომ CVE-ების უმეტესობა იყოფა შემდეგ კატეგორიებად: სერვისის უარყოფა (DoS), კოდის შესრულება, გადადინება, მეხსიერების გაფუჭება, ინფორმაციის გაჟონვა (ექსფილტრაცია) და პრივილეგიების გაძლიერება. მიუხედავად იმისა, რომ ბევრი CVE მრავალჯერ არის დათვლილი სხვადასხვა კატეგორიებში, ზოგადად ერთიდაიგივე საკითხები გრძელდება წლიდან წლამდე. სტატიის შემდეგ ნაწილში ჩვენ შევაფასებთ დაცვის სხვადასხვა სქემების გამოყენებას ამ მოწყვლადობის გამოყენების თავიდან ასაცილებლად.

Fig. 2

ამოცანები

ამ სტატიაში ჩვენ ვაპირებთ ვუპასუხოთ შემდეგ კითხვებს:

• რა არის Linux-ის სხვადასხვა დისტრიბუციის უსაფრთხოება? რა დაცვის მექანიზმები არსებობს ბირთვისა და მომხმარებლის სივრცის აპლიკაციებში?
• როგორ შეიცვალა უსაფრთხოების მექანიზმების მიღება დროთა განმავლობაში დისტრიბუციებში?
• როგორია პაკეტებისა და ბიბლიოთეკების საშუალო დამოკიდებულება თითოეული განაწილებისთვის?
• რა დაცვა ხორციელდება თითოეული ბინარისთვის?

დისტრიბუციების შერჩევა

გამოდის, რომ ძნელია ზუსტი სტატისტიკის პოვნა სადისტრიბუციო ინსტალაციების შესახებ, რადგან უმეტეს შემთხვევაში ჩამოტვირთვების რაოდენობა არ მიუთითებს რეალურ ინსტალაციის რაოდენობაზე. ამასთან, Unix-ის ვარიანტები შეადგენენ სერვერული სისტემების უმრავლესობას (ვებ სერვერებზე 69,2%, მა სტატისტიკა W3techs და სხვა წყაროები) და მათი წილი მუდმივად იზრდება. ამრიგად, ჩვენი კვლევისთვის ჩვენ ფოკუსირებული ვიყავით პლატფორმაზე არსებული დისტრიბუციებზე Google Cloud. კერძოდ, ჩვენ შევარჩიეთ შემდეგი OS:

დისტრიბუცია/ვერსია
ძირითადი
აშენება

OpenSUSE 12.4
4.12.14-95.3-ნაგულისხმევი
#1 SMP ოთხშაბათი 5 დეკემბერი 06:00:48 UTC 2018 (63a8d29)

Debian 9 (გაჭიმვა)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP სამ იან 15 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP პარასკევი 1 თებერვალი 14:54:57 UTC 2019

Red Hat Enterprise Linux სერვერი 6.10 (სანტიაგო)
2.6.32-754.9.1.el6.x86_64
#1 SMP ოთხ 21 ნოემბერი 15:08:21 EST 2018 წ

Red Hat Enterprise Linux სერვერი 7.6 (Maipo)
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…

Ubuntu 16.04 (Xenial Xerus)
4.15.0-1026-გკ
#27~16.04.1-Ubuntu SMP პარასკევი 7 დეკ. 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0-1026-გკ
#27-Ubuntu SMP ხუთ 6 დეკემბერი 18:27:01 UTC 2018

მაგიდის 1

ანალიზი

მოდით შევისწავლოთ ბირთვის ნაგულისხმევი კონფიგურაცია, ისევე როგორც პაკეტების თვისებები, რომლებიც ხელმისაწვდომია თითოეული დისტრიბუციის პაკეტის მენეჯერის მეშვეობით. ამრიგად, ჩვენ განვიხილავთ მხოლოდ პაკეტებს თითოეული დისტრიბუციის ნაგულისხმევი სარკეებიდან, უგულებელყოფთ პაკეტებს არასტაბილური საცავებიდან (როგორიცაა Debian-ის „ტესტირება“ სარკეები) და მესამე მხარის პაკეტები (როგორიცაა Nvidia პაკეტები სტანდარტული სარკეებიდან). გარდა ამისა, ჩვენ არ განვიხილავთ ბირთვის მორგებულ კომპილაციებს ან უსაფრთხოების გამაგრებულ კონფიგურაციებს.

ბირთვის კონფიგურაციის ანალიზი

ჩვენ გამოვიყენეთ ანალიზის სკრიპტი საფუძველზე უფასო kconfig შემოწმება. მოდით შევხედოთ დასახელებული დისტრიბუციების დაცვის პარამეტრებს და შევადაროთ ისინი ჩამონათვალს ძირითადი თვითდაცვის პროექტი (KSPP). თითოეული კონფიგურაციის ვარიანტისთვის, ცხრილი 2 აღწერს სასურველ პარამეტრს: ჩამრთველი არის დისტრიბუციებისთვის, რომლებიც შეესაბამება KSSP რეკომენდაციებს (ტერმინების ახსნისთვის იხილეთ ქვემოთ). აქ; მომავალ სტატიებში ჩვენ აგიხსნით უსაფრთხოების ამ მეთოდებიდან რამდენი გაჩნდა და როგორ უნდა გატეხოთ სისტემა მათი არყოფნის შემთხვევაში).

ზოგადად, ახალ ბირთვებს უფრო მკაცრი პარამეტრები აქვთ. მაგალითად, CentOS 6.10 და RHEL 6.10 2.6.32 ბირთვზე არ გააჩნიათ კრიტიკული მახასიათებლების უმეტესი ნაწილი, რომლებიც დანერგილია ახალ ბირთვებში, როგორიცაა სმაპი, მკაცრი RWX ნებართვები, მისამართის რანდომიზაცია ან copy2usr დაცვა. უნდა აღინიშნოს, რომ ცხრილის კონფიგურაციის მრავალი ვარიანტი არ არის ხელმისაწვდომი ბირთვის ძველ ვერსიებში და არ გამოიყენება სინამდვილეში - ეს ჯერ კიდევ ცხრილშია მითითებული, როგორც სათანადო დაცვის ნაკლებობა. ანალოგიურად, თუ კონფიგურაციის ვარიანტი არ არის მოცემულ ვერსიაში და უსაფრთხოება მოითხოვს ამ პარამეტრის გამორთვას, ეს ითვლება გონივრულ კონფიგურაციად.

კიდევ ერთი პუნქტი, რომელიც გასათვალისწინებელია შედეგების ინტერპრეტაციისას: ზოგიერთი ბირთვის კონფიგურაცია, რომელიც ზრდის თავდასხმის ზედაპირს, ასევე შეიძლება გამოყენებულ იქნას უსაფრთხოებისთვის. ასეთ მაგალითებს მიეკუთვნება uprobes და kprobes, ბირთვის მოდულები და BPF/eBPF. ჩვენი რეკომენდაციაა ზემოაღნიშნული მექანიზმების გამოყენება რეალური დაცვის უზრუნველსაყოფად, რადგან მათი გამოყენება არატრივიალურია და მათი ექსპლუატაცია გულისხმობს, რომ მავნე აქტორებმა უკვე დაამკვიდრეს ფეხი სისტემაში. მაგრამ თუ ეს პარამეტრები ჩართულია, სისტემის ადმინისტრატორმა აქტიურად უნდა აკონტროლოს ბოროტად გამოყენება.

ცხრილის 2-ში ჩანაწერების შემდგომი გადახედვისას, ჩვენ ვხედავთ, რომ თანამედროვე ბირთვები გთავაზობთ რამდენიმე ვარიანტს დაუცველობისგან დასაცავად, როგორიცაა ინფორმაციის გაჟონვა და დასტა/გროვის გადინება. თუმცა, ჩვენ შევნიშნავთ, რომ უახლესი პოპულარული დისტრიბუციებიც კი ჯერ არ განხორციელებულა უფრო რთული დაცვა (მაგალითად, პატჩებით grsecurity) ან თანამედროვე დაცვა კოდის ხელახალი გამოყენების შეტევებისგან (მაგ. რანდომიზაციის კომბინაცია სქემებთან, როგორიცაა R^X კოდისთვის). კიდევ უფრო უარესი, ეს უფრო მოწინავე თავდაცვაც კი არ იცავს თავდასხმების მთელ სპექტრს. აქედან გამომდინარე, ძალიან მნიშვნელოვანია სისტემის ადმინისტრატორებისთვის შეავსონ ჭკვიანი კონფიგურაციები გადაწყვეტილებებით, რომლებიც გვთავაზობენ ექსპლოიტის გაშვების გამოვლენას და პრევენციას.

განაცხადის ანალიზი

გასაკვირი არ არის, რომ სხვადასხვა დისტრიბუციას აქვს სხვადასხვა პაკეტის მახასიათებლები, კომპილაციის ვარიანტები, ბიბლიოთეკის დამოკიდებულებები და ა.შ. დაკავშირებული დისტრიბუციები და პაკეტები მცირე რაოდენობის დამოკიდებულებით (მაგალითად, coreutils Ubuntu-ზე ან Debian-ზე). განსხვავებების შესაფასებლად, ჩვენ ჩამოვტვირთეთ ყველა ხელმისაწვდომი პაკეტი, ამოვიღეთ მათი შინაარსი და გავაანალიზეთ ბინარები და დამოკიდებულებები. თითოეული პაკეტისთვის ჩვენ თვალყურს ვადევნებდით სხვა პაკეტებს, რომლებზედაც ეს დამოკიდებულია და თითოეული ბინარისთვის ვაკვირდებოდით მის დამოკიდებულებებს. ამ ნაწილში ჩვენ მოკლედ ვაჯამებთ დასკვნებს.

დისტრიბუციები

საერთო ჯამში, ჩვენ გადმოვწერეთ 361 პაკეტი ყველა დისტრიბუციისთვის, ამოიღეთ მხოლოდ პაკეტები ნაგულისხმევი სარკეებიდან. ჩვენ უგულებელვყავით პაკეტები ELF შესრულებადი ფაილების გარეშე, როგორიცაა წყაროები, შრიფტები და ა.შ. გაფილტვრის შემდეგ დარჩა 556 პაკეტი, რომელიც შეიცავს სულ 129 ბინარს. პაკეტებისა და ფაილების განაწილება დისტრიბუციებში ნაჩვენებია ნახ. 569.

Fig. 3

თქვენ შეიძლება შეამჩნიოთ, რომ რაც უფრო თანამედროვეა დისტრიბუცია, მით მეტ პაკეტს და ბინაარს შეიცავს, რაც ლოგიკურია. თუმცა, Ubuntu და Debian პაკეტები მოიცავს უფრო მეტ ბინარებს (როგორც შესრულებადი, ასევე დინამიური მოდულები და ბიბლიოთეკები), ვიდრე CentOS, SUSE და RHEL, რაც პოტენციურად იმოქმედებს Ubuntu-სა და Debian-ის თავდასხმის ზედაპირზე (უნდა აღინიშნოს, რომ რიცხვები ასახავს ყველა ვერსიის ყველა ბინაარს. პაკეტი, ანუ ზოგიერთი ფაილი გაანალიზებულია რამდენჯერმე). ეს განსაკუთრებით მნიშვნელოვანია, როდესაც განიხილავთ დამოკიდებულებებს პაკეტებს შორის. ამრიგად, ერთი პაკეტის ბინარულ დაუცველობას შეუძლია გავლენა მოახდინოს ეკოსისტემის ბევრ ნაწილზე, ისევე როგორც დაუცველ ბიბლიოთეკას შეუძლია გავლენა მოახდინოს ყველა ბინარზე, რომელიც მას იმპორტირებს. როგორც ამოსავალი წერტილი, მოდით შევხედოთ დამოკიდებულების რაოდენობის განაწილებას პაკეტებს შორის სხვადასხვა ოპერაციულ სისტემაში:

Fig. 4

თითქმის ყველა დისტრიბუციაში, პაკეტების 60%-ს აქვს მინიმუმ 10 დამოკიდებულება. გარდა ამისა, ზოგიერთ პაკეტს აქვს დამოკიდებულების მნიშვნელოვნად დიდი რაოდენობა (100-ზე მეტი). იგივე ეხება საპირისპირო პაკეტების დამოკიდებულებებს: როგორც მოსალოდნელი იყო, რამდენიმე პაკეტს იყენებენ მრავალი სხვა პაკეტი დისტრიბუციაში, ამიტომ დაუცველობა ამ რამდენიმე არჩევანში მაღალი რისკის შემცველია. მაგალითად, შემდეგი ცხრილი ჩამოთვლის 20 პაკეტს საპირისპირო დამოკიდებულების მაქსიმალური რაოდენობით SLES, Centos 7, Debian 9 და Ubuntu 18.04-ში (თითოეული უჯრედი მიუთითებს პაკეტს და საპირისპირო დამოკიდებულებების რაოდენობას).

მაგიდის 3

Საინტერესო ფაქტი. მიუხედავად იმისა, რომ ყველა გაანალიზებული OS აგებულია x86_64 არქიტექტურისთვის და პაკეტების უმეტესობას აქვს არქიტექტურა განსაზღვრული როგორც x86_64 და x86, პაკეტები ხშირად შეიცავს ბინარებს სხვა არქიტექტურებისთვის, როგორც ეს ნაჩვენებია სურათზე 5. XNUMX.

Fig. 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: ჩართულია თუ არა სტეკ კანარის დაცვა დასტა შეჯახებისგან თავდასხმებისგან.
• Fortify Source: შეიცვლება თუ არა არაუსაფრთხო ფუნქციები (მაგალითად, strcpy) მათი უფრო უსაფრთხო ანალოგებით და ზარები, რომლებიც შემოწმებულია გაშვების დროს, ჩანაცვლდება მათი შეუმოწმებელი კოლეგებით (მაგალითად, memcpy __memcpy_chk-ის ნაცვლად).
• მხოლოდ წაკითხვადი გადაადგილებები (RELRO): აღინიშნება თუ არა გადატანის ცხრილის ჩანაწერები მხოლოდ წაკითხვად, თუ ისინი ამოქმედდება შესრულების დაწყებამდე.
• დაუყოვნებელი დაკავშირება: საშუალებას იძლევა თუ არა გაშვების დროის დამაკავშირებელი ყველა მოძრაობა პროგრამის შესრულების დაწყებამდე (ეს არის სრული RELRO-ის ექვივალენტი).

საკმარისია თუ არა ზემოთ ჩამოთვლილი მექანიზმები? სამწუხაროდ არა. ცნობილია ყველა ზემოთ ჩამოთვლილი დაცვის გვერდის ავლით, მაგრამ რაც უფრო მკაცრია დაცვა, მით უფრო მაღალია ზოლი თავდამსხმელისთვის. Მაგალითად, RELRO შემოვლითი მეთოდები უფრო რთული გამოსაყენებელია, თუ PIE და დაუყოვნებელი სავალდებულოა ძალაში. ანალოგიურად, სრული ASLR მოითხოვს დამატებით მუშაობას სამუშაო ექსპლოიტის შესაქმნელად. თუმცა, დახვეწილი თავდამსხმელები უკვე მზად არიან შეხვდნენ ასეთ დაცვას: მათი არარსებობა არსებითად დააჩქარებს ჰაკერს. ამიტომ აუცილებელია, რომ ეს ზომები ჩაითვალოს საჭიროდ მინიმალური.

ჩვენ გვინდოდა შეგვესწავლა, თუ რამდენი ბინარული ფაილია მოცემულ დისტრიბუციაში დაცული ამ და სამი სხვა მეთოდით:

• შეუსრულებელი ბიტი (NX) ხელს უშლის შესრულებას ნებისმიერ რეგიონში, რომელიც არ უნდა იყოს შესრულებადი, როგორიცაა სტეკის გროვა და ა.შ.
• RPATH/RUNPATH აღნიშნავს შესრულების გზას, რომელსაც იყენებს დინამიური ჩამტვირთავი შესაბამისი ბიბლიოთეკების მოსაძებნად. პირველი არის სავალდებულო ნებისმიერი თანამედროვე სისტემისთვის: მისი არარსებობა საშუალებას აძლევს თავდამსხმელებს თვითნებურად ჩაწერონ დატვირთვა მეხსიერებაში და შეასრულონ ის ისე, როგორც არის. მეორე შემთხვევაში, შესრულების ბილიკის არასწორი კონფიგურაცია ხელს უწყობს არასანდო კოდის დანერგვას, რამაც შეიძლება გამოიწვიოს მთელი რიგი პრობლემები (მაგ. პრივილეგიების ესკალაციადა სხვა პრობლემები).
• სტეკის შეჯახებისგან დაცვა უზრუნველყოფს თავდასხმებისგან დაცვას, რაც იწვევს დატის მეხსიერების სხვა სფეროების გადაფარვას (როგორიცაა გროვა). ბოლოდროინდელი ბოროტად გამოყენების გათვალისწინებით სისტემური გროვის შეჯახების დაუცველობა, მიზანშეწონილად მივიჩნიეთ ამ მექანიზმის ჩართვა ჩვენს მონაცემთა ბაზაში.

ასე რომ, ყოველგვარი შეფერხების გარეშე, მოდით გადავიდეთ ციფრებზე. ცხრილები 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 (შესაბამისი ფუნქციების განხორციელება შესრულებადი ფაილების მთლიანი რაოდენობის პროცენტულად)

ცხრილი 5. უსაფრთხოების მახასიათებლები ბიბლიოთეკებისთვის, რომლებიც ნაჩვენებია ნახ. 3 (შესაბამისი ფუნქციების განხორციელება ბიბლიოთეკების მთლიანი რაოდენობის პროცენტულად)

ანუ არის პროგრესი? ნამდვილად არის: ეს ჩანს ინდივიდუალური განაწილების სტატისტიკიდან (მაგალითად, Debian), ისევე როგორც ზემოთ მოცემული ცხრილებიდან. როგორც მაგალითი ნახ. სურათი 6 გვიჩვენებს დაცვის მექანიზმების დანერგვას Ubuntu LTS 5-ის სამ თანმიმდევრულ განაწილებაში (ჩვენ გამოვტოვეთ სტეკის შეჯახების დაცვის სტატისტიკა). ჩვენ ვამჩნევთ, რომ ვერსიიდან ვერსიამდე სულ უფრო მეტი ფაილი მხარს უჭერს stack canaries-ს და ასევე სულ უფრო მეტი ბინარია იგზავნება სრული RELRO დაცვით.

Fig. 6

სამწუხაროდ, რამდენიმე შესრულებად ფაილს სხვადასხვა დისტრიბუციაში ჯერ კიდევ არ გააჩნია ზემოაღნიშნული დაცვა. მაგალითად, თუ უყურებთ Ubuntu 18.04-ს, შეამჩნევთ ngetty ორობითობას (გეტის ჩანაცვლება), ისევე როგორც mksh და lksh ჭურვები, picolisp თარჯიმანი, nvidia-cuda-ინსტრუმენტარიუმის პაკეტები (პოპულარული პაკეტი GPU-ით დაჩქარებული აპლიკაციებისთვის. როგორიცაა მანქანათმცოდნეობის ჩარჩოები) და klibc -utils. ანალოგიურად, mandos-client ორობითი (ადმინისტრაციული ინსტრუმენტი, რომელიც საშუალებას გაძლევთ ავტომატურად გადატვირთოთ მანქანები დაშიფრული ფაილური სისტემებით) და rsh-redone-client (rsh და rlogin-ის ხელახალი განხორციელება) NX დაცვის გარეშე, თუმცა მათ აქვთ SUID უფლებები: (. ასევე, რამდენიმე suid ბინაარს აკლია ძირითადი დაცვა, როგორიცაა stack canaries (მაგალითად, Xorg.wrap ორობითი Xorg პაკეტიდან).

შეჯამება და დასკვნითი შენიშვნები

ამ სტატიაში ჩვენ გამოვყავით თანამედროვე Linux დისტრიბუციების უსაფრთხოების რამდენიმე მახასიათებელი. ანალიზმა აჩვენა, რომ უახლესი Ubuntu LTS დისტრიბუცია (18.04) ახორციელებს, საშუალოდ, უძლიერეს OS და აპლიკაციის დონის დაცვას შედარებით ახალი ბირთვების მქონე დისტრიბუციებს შორის, როგორიცაა 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%-ზე ნაკლებში.

და ბოლოს, უნდა აღინიშნოს, რომ მიუხედავად იმისა, რომ ჩვენ ჩავატარეთ კვლევა ხელით, არსებობს მრავალი უსაფრთხოების ინსტრუმენტი (მაგ. ლინსი, Tiger, Hubble), რომელიც ახორციელებს ანალიზს და ეხმარება თავიდან აიცილოს სახიფათო კონფიგურაციები. სამწუხაროდ, გონივრულ კონფიგურაციებში ძლიერი დაცვაც კი არ იძლევა ექსპლოიტების არარსებობის გარანტიას. ამიტომ ჩვენ მტკიცედ გვჯერა, რომ ეს სასიცოცხლოდ მნიშვნელოვანია საიმედო მონიტორინგი და თავდასხმების პრევენცია რეალურ დროში, ფოკუსირება ექსპლუატაციის შაბლონებზე და მათ პრევენციაზე.

წყარო: www.habr.com