TL; កុង. នៅក្នុងអត្ថបទនេះ យើងស្វែងយល់ពីគ្រោងការណ៍រឹងដែលដំណើរការចេញពីប្រអប់នៅលើការចែកចាយលីនុចដ៏ពេញនិយមចំនួនប្រាំ។ សម្រាប់នីមួយៗ យើងបានយកការកំណត់រចនាសម្ព័ន្ធខឺណែលលំនាំដើម ផ្ទុកកញ្ចប់ទាំងអស់ និងវិភាគគ្រោងការណ៍សុវត្ថិភាពនៅក្នុងប្រព័ន្ធគោលពីរដែលបានភ្ជាប់។ ការចែកចាយដែលត្រូវបានពិចារណាគឺ OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 និង 7 ក៏ដូចជា Ubuntu 14.04, 12.04 និង 18.04 LTS ។

លទ្ធផលបញ្ជាក់ថា សូម្បីតែគ្រោងការណ៍មូលដ្ឋាន ដូចជាការដាក់ជង់ Canaries និងលេខកូដឯករាជ្យទីតាំង មិនទាន់ត្រូវបានទទួលយកដោយមនុស្សគ្រប់គ្នានៅឡើយ។ ស្ថានភាពកាន់តែអាក្រក់សម្រាប់អ្នកចងក្រងនៅពេលនិយាយអំពីការការពារប្រឆាំងនឹងភាពងាយរងគ្រោះដូចជា stack clash ដែលបានចាប់អារម្មណ៍នៅក្នុងខែមករាបន្ទាប់ពីការបោះពុម្ពផ្សាយ ព័ត៌មានអំពីភាពងាយរងគ្រោះនៃប្រព័ន្ធ. ប៉ុន្តែមិនមែនអ្វីៗទាំងអស់សុទ្ធតែអស់សង្ឃឹមនោះទេ។ ចំនួនគោលពីរសំខាន់ៗអនុវត្តវិធីសាស្រ្តការពារជាមូលដ្ឋាន ហើយចំនួនរបស់ពួកគេកើនឡើងពីកំណែមួយទៅកំណែមួយ។

ការពិនិត្យឡើងវិញបានបង្ហាញថាវិធីសាស្ត្រការពារចំនួនច្រើនបំផុតត្រូវបានអនុវត្តនៅក្នុង Ubuntu 18.04 នៅកម្រិត OS និងកម្មវិធី បន្ទាប់មកដោយ Debian 9។ ម្យ៉ាងវិញទៀត OpenSUSE 12.4, CentOS 7 និង RHEL 7 ក៏អនុវត្តគ្រោងការណ៍ការពារជាមូលដ្ឋាន និងការការពារការប៉ះទង្គិចជង់ផងដែរ។ ត្រូវ​បាន​ប្រើ​កាន់​តែ​ទូលំ​ទូលាយ​ជាមួយ​នឹង​សំណុំ​កញ្ចប់​លំនាំដើម​ដែល​ក្រាស់​ជាង។

សេចក្តីណែនាំ

វាពិបាកក្នុងការធានានូវកម្មវិធីដែលមានគុណភាពខ្ពស់។ ទោះបីជាមានឧបករណ៍ទំនើបៗជាច្រើនសម្រាប់ការវិភាគកូដឋិតិវន្ត និងការវិភាគពេលដំណើរការថាមវន្ត ក៏ដូចជាការវិវឌ្ឍន៍ដ៏សំខាន់ក្នុងការអភិវឌ្ឍន៍កម្មវិធីចងក្រង និងភាសាសរសេរកម្មវិធីក៏ដោយ ក៏កម្មវិធីទំនើបនៅតែទទួលរងនូវភាពងាយរងគ្រោះដែលត្រូវបានវាយប្រហារដោយអ្នកវាយប្រហារឥតឈប់ឈរ។ ស្ថានភាពកាន់តែអាក្រក់នៅក្នុងប្រព័ន្ធអេកូឡូស៊ីដែលរួមបញ្ចូលកូដកេរ្តិ៍។ ក្នុងករណីបែបនេះ យើងមិនត្រឹមតែប្រឈមមុខនឹងបញ្ហាអស់កល្បជានិច្ចនៃការស្វែងរកកំហុសដែលអាចកេងប្រវ័ញ្ចបានប៉ុណ្ណោះទេ ប៉ុន្តែយើងក៏ត្រូវបានកំណត់ដោយក្របខណ្ឌភាពត្រូវគ្នាថយក្រោយយ៉ាងតឹងរឹង ដែលជារឿយៗតម្រូវឱ្យយើងរក្សាកូដដែលមានកម្រិត ឬកាន់តែអាក្រក់ជាងនេះទៅទៀត ងាយរងគ្រោះ ឬកូដកំហុស។

នេះគឺជាកន្លែងដែលវិធីសាស្រ្តនៃការការពារ ឬកម្មវិធីរឹងបានចូលមកលេង។ យើងមិនអាចការពារប្រភេទនៃកំហុសមួយចំនួនបានទេ ប៉ុន្តែយើងអាចធ្វើឱ្យជីវិតរបស់អ្នកវាយប្រហារកាន់តែលំបាក និងដោះស្រាយបញ្ហាដោយផ្នែកដោយការទប់ស្កាត់ ឬការពារ។ ការកេងប្រវ័ញ្ច កំហុសទាំងនេះ។ ការការពារបែបនេះត្រូវបានប្រើនៅក្នុងប្រព័ន្ធប្រតិបត្តិការទំនើបទាំងអស់ ប៉ុន្តែវិធីសាស្រ្តខុសគ្នាយ៉ាងខ្លាំងនៅក្នុងភាពស្មុគស្មាញ ប្រសិទ្ធភាព និងការអនុវត្ត៖ ពីជង់ Canaries និង ASLR ដល់ការការពារពេញលេញ CFI и R.O.P.. នៅក្នុងអត្ថបទនេះ យើងនឹងពិនិត្យមើលថាតើវិធីសាស្ត្រសុវត្ថិភាពអ្វីខ្លះដែលត្រូវបានប្រើនៅក្នុងការចែកចាយលីនុចដ៏ពេញនិយមបំផុតនៅក្នុងការកំណត់រចនាសម្ព័ន្ធលំនាំដើម ហើយក៏ពិនិត្យមើលលក្ខណៈសម្បត្តិរបស់ប្រព័ន្ធគោលពីរដែលត្រូវបានចែកចាយតាមរយៈប្រព័ន្ធគ្រប់គ្រងកញ្ចប់នៃការចែកចាយនីមួយៗផងដែរ។

CVE និងសុវត្ថិភាព

យើងទាំងអស់គ្នាបានឃើញអត្ថបទដែលមានចំណងជើងដូចជា "កម្មវិធីដែលងាយរងគ្រោះបំផុតប្រចាំឆ្នាំ" ឬ "ប្រព័ន្ធប្រតិបត្តិការដែលងាយរងគ្រោះបំផុត"។ ជាធម្មតាពួកគេផ្តល់ស្ថិតិលើចំនួនសរុបនៃកំណត់ត្រាអំពីភាពងាយរងគ្រោះដូចជា CVE (ភាពងាយរងគ្រោះ និងការបង្ហាញទូទៅ), ទទួលបានពី មូលដ្ឋានទិន្នន័យភាពងាយរងគ្រោះជាតិ (NVD) ពី NIST និងប្រភពផ្សេងទៀត។ ជាបន្តបន្ទាប់ កម្មវិធី ឬ OS ទាំងនេះត្រូវបានចាត់ថ្នាក់ដោយចំនួន CVEs ។ ជាអកុសល ខណៈពេលដែល CVEs មានប្រយោជន៍ខ្លាំងណាស់សម្រាប់ការតាមដានបញ្ហា និងការជូនដំណឹងដល់អ្នកលក់ និងអ្នកប្រើប្រាស់ ពួកគេនិយាយតិចតួចអំពីសុវត្ថិភាពពិតប្រាកដនៃកម្មវិធី។

ជាឧទាហរណ៍ សូមពិចារណាចំនួនសរុបនៃ CVEs ក្នុងរយៈពេល XNUMX ឆ្នាំចុងក្រោយនេះសម្រាប់ខឺណែលលីនុច និងការចែកចាយម៉ាស៊ីនមេដ៏ពេញនិយមបំផុតចំនួនប្រាំគឺ Ubuntu, Debian, Red Hat Enterprise Linux និង OpenSUSE ។

រូបភព។ មួយ

តើក្រាហ្វនេះប្រាប់យើងអ្វីខ្លះ? តើចំនួន CVEs ខ្ពស់មានន័យថាការចែកចាយមួយគឺងាយរងគ្រោះជាងមួយផ្សេងទៀត? គ្មាន​ចម្លើយ។ ជាឧទាហរណ៍ នៅក្នុងអត្ថបទនេះ អ្នកនឹងឃើញថា Debian មានយន្តការសុវត្ថិភាពខ្លាំងជាងបើប្រៀបធៀបទៅនឹង OpenSUSE ឬ RedHat Linux ហើយ Debian មាន CVEs ច្រើនជាងនេះ។ ទោះជាយ៉ាងណាក៏ដោយ ពួកវាមិនមានន័យថាសុវត្ថិភាពខ្សោយនោះទេ៖ សូម្បីតែវត្តមានរបស់ CVE ក៏មិនបង្ហាញថាតើភាពងាយរងគ្រោះគឺ កេងប្រវ័ញ្ច. ពិន្ទុនៃភាពធ្ងន់ធ្ងរផ្តល់នូវការចង្អុលបង្ហាញពីរបៀប ប្រហែលជា ការកេងប្រវ័ញ្ចលើភាពងាយរងគ្រោះ ប៉ុន្តែទីបំផុតការកេងប្រវ័ញ្ចគឺពឹងផ្អែកយ៉ាងខ្លាំងទៅលើការការពារដែលមាននៅក្នុងប្រព័ន្ធដែលរងផលប៉ះពាល់ និងធនធាន និងសមត្ថភាពរបស់អ្នកវាយប្រហារ។ លើសពីនេះទៅទៀត អវត្ដមាននៃរបាយការណ៍ CVE មិននិយាយអ្វីអំពីអ្នកដទៃទេ។ មិនបានចុះឈ្មោះ ឬមិនស្គាល់ ភាពងាយរងគ្រោះ។ ភាពខុសគ្នានៅក្នុង CVE អាចបណ្តាលមកពីកត្តាផ្សេងពីគុណភាពកម្មវិធី រួមទាំងធនធានដែលបានបម្រុងទុកសម្រាប់ការធ្វើតេស្ត ឬទំហំនៃមូលដ្ឋានអ្នកប្រើប្រាស់។ ក្នុងឧទាហរណ៍របស់យើង ចំនួន CVEs ខ្ពស់របស់ Debian អាចបង្ហាញយ៉ាងសាមញ្ញថា Debian ដឹកជញ្ជូនកញ្ចប់កម្មវិធីកាន់តែច្រើន។

ជាការពិតណាស់ ប្រព័ន្ធ CVE ផ្តល់ព័ត៌មានមានប្រយោជន៍ ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតការការពារសមស្រប។ កាលណាយើងយល់កាន់តែច្បាស់អំពីមូលហេតុនៃការបរាជ័យនៃកម្មវិធី នោះវាកាន់តែងាយស្រួលក្នុងការកំណត់វិធីសាស្រ្តនៃការកេងប្រវ័ញ្ច និងបង្កើតយន្តការសមស្រប ការរកឃើញនិងការឆ្លើយតប. នៅក្នុងរូបភព។ រូបភាពទី 2 បង្ហាញពីប្រភេទភាពងាយរងគ្រោះសម្រាប់ការចែកចាយទាំងអស់ក្នុងរយៈពេល XNUMX ឆ្នាំចុងក្រោយនេះ (ប្រភព) វាច្បាស់ណាស់ថា CVEs ភាគច្រើនធ្លាក់ចូលទៅក្នុងប្រភេទដូចខាងក្រោម៖ ការបដិសេធសេវាកម្ម (DoS) ការប្រតិបត្តិកូដ ការហូរហៀរ អំពើពុករលួយនៃអង្គចងចាំ ការលេចធ្លាយព័ត៌មាន (ការបណ្តេញចេញ) និងការកើនឡើងសិទ្ធិ។ ទោះបីជា CVEs ជាច្រើនត្រូវបានរាប់ច្រើនដងក្នុងប្រភេទផ្សេងៗគ្នាក៏ដោយ ជាទូទៅបញ្ហាដូចគ្នានៅតែបន្តកើតមានពីមួយឆ្នាំទៅមួយឆ្នាំ។ នៅក្នុងផ្នែកបន្ទាប់នៃអត្ថបទ យើងនឹងវាយតម្លៃការប្រើប្រាស់គ្រោងការណ៍ការពារផ្សេងៗដើម្បីការពារការកេងប្រវ័ញ្ចលើភាពងាយរងគ្រោះទាំងនេះ។

រូបភព។ មួយ

ភារកិច្ច

នៅក្នុងអត្ថបទនេះ យើងចង់ឆ្លើយសំណួរខាងក្រោម៖

• តើអ្វីទៅជាសុវត្ថិភាពនៃការចែកចាយលីនុចផ្សេងៗគ្នា? តើយន្តការការពារអ្វីខ្លះដែលមាននៅក្នុងខឺណែល និងកម្មវិធីចន្លោះអ្នកប្រើប្រាស់?
• តើការទទួលយកយន្តការសន្តិសុខបានផ្លាស់ប្តូរតាមពេលវេលា តាមរយៈការចែកចាយយ៉ាងដូចម្តេច?
• តើអ្វីទៅជាភាពអាស្រ័យជាមធ្យមនៃកញ្ចប់ និងបណ្ណាល័យសម្រាប់ការចែកចាយនីមួយៗ?
• តើការការពារអ្វីខ្លះត្រូវបានអនុវត្តសម្រាប់ប្រព័ន្ធគោលពីរនីមួយៗ?

ការជ្រើសរើសការចែកចាយ

វាប្រែថាវាពិបាកក្នុងការស្វែងរកស្ថិតិត្រឹមត្រូវលើការដំឡើងការចែកចាយព្រោះក្នុងករណីភាគច្រើនចំនួននៃការទាញយកមិនបង្ហាញពីចំនួននៃការដំឡើងពិតប្រាកដនោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ វ៉ារ្យ៉ង់ Unix បង្កើតបានជាប្រព័ន្ធម៉ាស៊ីនមេភាគច្រើន (នៅលើម៉ាស៊ីនមេបណ្តាញ 69,2%, ដោយ ស្ថិតិ W3techs និងប្រភពផ្សេងទៀត) ហើយចំណែករបស់ពួកគេកំពុងកើនឡើងឥតឈប់ឈរ។ ដូច្នេះ សម្រាប់ការស្រាវជ្រាវរបស់យើង យើងបានផ្តោតលើការចែកចាយដែលមានចេញពីប្រអប់នៅលើវេទិកា Google Cloud . ជាពិសេស យើងបានជ្រើសរើស OS ដូចខាងក្រោម៖

ការចែកចាយ / កំណែ
ស្នូល
សាងសង់

អូផឹនស៊ូស៊ី ១៥
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 Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP ថ្ងៃពុធ ទី 21 ខែវិច្ឆិកា ម៉ោង 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Thu Nov 15 17:36:42 UTC 2018

អ៊ូប៊ុនទូ 14.04 (Trusty Tahr)
4.4.0–140-ទូទៅ

#166~14.04.1-អ៊ូប៊ុនទូ SMP សៅរ៍ 17 វិច្ឆិកា 01:52:43 UTC 20…

អ៊ូប៊ុនទូ 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-អ៊ូប៊ុនទូ SMP ថ្ងៃសុក្រ ទី 7 ខែធ្នូ 09:59:47 UTC 2018

អ៊ូប៊ុនទូ 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27- Ubuntu SMP Thu Dec 6 18:27:01 UTC 2018

តារាង 1

Анализ

ចូរយើងសិក្សាការកំណត់រចនាសម្ព័ន្ធខឺណែលលំនាំដើម ក៏ដូចជាលក្ខណៈសម្បត្តិនៃកញ្ចប់ដែលមានតាមរយៈកម្មវិធីគ្រប់គ្រងកញ្ចប់នៃការចែកចាយនីមួយៗចេញពីប្រអប់។ ដូច្នេះហើយ យើងពិចារណាតែកញ្ចប់ពីកញ្ចក់លំនាំដើមនៃការចែកចាយនីមួយៗ ដោយមិនអើពើកញ្ចប់ពីឃ្លាំងមិនស្ថិតស្ថេរ (ដូចជាកញ្ចក់ 'ការសាកល្បង' របស់ Debian) និងកញ្ចប់ភាគីទីបី (ដូចជាកញ្ចប់ Nvidia ពីកញ្ចក់ស្តង់ដារ)។ លើសពីនេះទៀត យើងមិនគិតពីការចងក្រងខឺណែលផ្ទាល់ខ្លួន ឬការកំណត់រចនាសម្ព័ន្ធរឹងដោយសុវត្ថិភាពទេ។

ការវិភាគការកំណត់រចនាសម្ព័ន្ធខឺណែល

យើងបានអនុវត្តស្គ្រីបការវិភាគដោយផ្អែកលើ កម្មវិធីពិនិត្យ kconfig ឥតគិតថ្លៃ. សូមក្រឡេកមើលប៉ារ៉ាម៉ែត្រការពារក្រៅប្រអប់នៃការចែកចាយដែលមានឈ្មោះ ហើយប្រៀបធៀបពួកវាជាមួយបញ្ជីពី គម្រោងការពារខ្លួនឯងស្នូល (KSPP) ។ សម្រាប់ជម្រើសនៃការកំណត់រចនាសម្ព័ន្ធនីមួយៗ តារាងទី 2 ពិពណ៌នាអំពីការកំណត់ដែលចង់បាន៖ ប្រអប់ធីកគឺសម្រាប់ការចែកចាយដែលអនុលោមតាមការណែនាំរបស់ KSSP (សូមមើលខាងក្រោមសម្រាប់ការពន្យល់អំពីលក្ខខណ្ឌ)។ នៅទីនេះ; នៅក្នុងអត្ថបទនាពេលខាងមុខ យើងនឹងពន្យល់ពីរបៀបដែលវិធីសាស្រ្តសុវត្ថិភាពទាំងនេះត្រូវបានបង្កើតឡើង និងរបៀប hack ប្រព័ន្ធនៅពេលអវត្តមានរបស់ពួកគេ)។

ជាទូទៅ ខឺណែលថ្មីមានការកំណត់កាន់តែតឹងរ៉ឹងចេញពីប្រអប់។ ឧទាហរណ៍ CentOS 6.10 និង RHEL 6.10 នៅលើខឺណែល 2.6.32 ខ្វះលក្ខណៈពិសេសសំខាន់ៗជាច្រើនដែលត្រូវបានអនុវត្តនៅក្នុងខឺណែលថ្មីៗដូចជា SMAPការអនុញ្ញាត RWX ដ៏តឹងរ៉ឹង ការចៃដន្យអាសយដ្ឋាន ឬការការពារ copy2usr ។ វាគួរតែត្រូវបានកត់សម្គាល់ថាជម្រើសនៃការកំណត់រចនាសម្ព័ន្ធជាច្រើននៅក្នុងតារាងគឺមិនមាននៅក្នុងកំណែចាស់នៃខឺណែលហើយមិនអាចអនុវត្តបាននៅក្នុងការពិត - នេះនៅតែត្រូវបានចង្អុលបង្ហាញនៅក្នុងតារាងថាជាកង្វះការការពារត្រឹមត្រូវ។ ដូចគ្នានេះដែរ ប្រសិនបើជម្រើសនៃការកំណត់រចនាសម្ព័ន្ធមិនមានវត្តមាននៅក្នុងកំណែដែលបានផ្តល់ឱ្យ ហើយសុវត្ថិភាពទាមទារឱ្យបិទជម្រើសនោះ វាត្រូវបានចាត់ទុកថាជាការកំណត់សមហេតុផល។

ចំណុចមួយទៀតដែលត្រូវពិចារណានៅពេលបកស្រាយលទ្ធផល៖ ការកំណត់រចនាសម្ព័ន្ធខឺណែលមួយចំនួនដែលបង្កើនផ្ទៃវាយប្រហារក៏អាចប្រើសម្រាប់សុវត្ថិភាពផងដែរ។ ឧទាហរណ៍បែបនេះរួមមាន uprobes និង kprobes ម៉ូឌុលខឺណែល និង BPF/eBPF ។ អនុសាសន៍របស់យើងគឺត្រូវប្រើយន្តការខាងលើ ដើម្បីផ្តល់ការការពារពិតប្រាកដ ព្រោះថាពួកវាមិនមែនជារឿងតូចតាចក្នុងការប្រើប្រាស់ ហើយការកេងប្រវ័ញ្ចរបស់ពួកគេសន្មត់ថាអ្នកប្រព្រឹត្តអាក្រក់បានបង្កើតមូលដ្ឋាននៅក្នុងប្រព័ន្ធរួចហើយ។ ប៉ុន្តែប្រសិនបើជម្រើសទាំងនេះត្រូវបានបើក អ្នកគ្រប់គ្រងប្រព័ន្ធត្រូវតែត្រួតពិនិត្យយ៉ាងសកម្មចំពោះការបំពាន។

ក្រឡេកមើលបន្ថែមលើធាតុនៅក្នុងតារាងទី 2 យើងឃើញថា ខឺណែលទំនើបផ្តល់នូវជម្រើសជាច្រើនសម្រាប់ការការពារប្រឆាំងនឹងការកេងប្រវ័ញ្ចនៃភាពងាយរងគ្រោះ ដូចជាការលេចធ្លាយព័ត៌មាន និងការហូរហៀរជង់/ហ៊ាប។ ទោះជាយ៉ាងណាក៏ដោយ យើងសង្កេតឃើញថា សូម្បីតែការចែកចាយដ៏ពេញនិយមថ្មីៗបំផុត មិនទាន់បានអនុវត្តការការពារស្មុគស្មាញជាងនេះទេ (ឧទាហរណ៍ ជាមួយបំណះ សុវត្ថិភាព) ឬការការពារទំនើបប្រឆាំងនឹងការវាយប្រហារដោយប្រើកូដឡើងវិញ (ឧ. ការរួមបញ្ចូលគ្នានៃការចៃដន្យជាមួយគ្រោងការណ៍ដូចជា R^X សម្រាប់កូដ) ដើម្បីធ្វើឱ្យបញ្ហាកាន់តែអាក្រក់ សូម្បីតែការការពារកម្រិតខ្ពស់ជាងនេះក៏មិនការពារប្រឆាំងនឹងការវាយប្រហារពេញលេញដែរ។ ដូច្នេះ វាមានសារៈសំខាន់ណាស់សម្រាប់អ្នកគ្រប់គ្រងប្រព័ន្ធក្នុងការបំពេញបន្ថែមការកំណត់រចនាសម្ព័ន្ធឆ្លាតវៃជាមួយនឹងដំណោះស្រាយដែលផ្តល់នូវការរកឃើញ និងការការពារការកេងប្រវ័ញ្ចពេលដំណើរការ។

ការវិភាគកម្មវិធី

មិនគួរឱ្យភ្ញាក់ផ្អើលទេ ការចែកចាយផ្សេងៗគ្នាមានលក្ខណៈកញ្ចប់ខុសៗគ្នា ជម្រើសនៃការចងក្រង ភាពអាស្រ័យបណ្ណាល័យ។ល។ ភាពខុសគ្នាមានសូម្បីតែសម្រាប់ ពាក់ព័ន្ធ ការចែកចាយ និងកញ្ចប់ដែលមានចំនួនតិចតួចនៃការពឹងផ្អែក (ឧទាហរណ៍ ស្នូលនៅលើអ៊ូប៊ុនទូ ឬដេបៀន)។ ដើម្បីវាយតម្លៃភាពខុសគ្នា យើងបានទាញយកកញ្ចប់ដែលមានទាំងអស់ ទាញយកខ្លឹមសាររបស់វា និងវិភាគប្រព័ន្ធគោលពីរ និងភាពអាស្រ័យ។ សម្រាប់កញ្ចប់នីមួយៗ យើងបានតាមដានកញ្ចប់ផ្សេងទៀតដែលវាអាស្រ័យលើ ហើយសម្រាប់ប្រព័ន្ធគោលពីរនីមួយៗ យើងបានតាមដានភាពអាស្រ័យរបស់វា។ នៅក្នុងផ្នែកនេះ យើងសង្ខេបការសន្និដ្ឋានដោយសង្ខេប។

ការចែកចាយ

សរុបមក យើងបានទាញយកកញ្ចប់ចំនួន 361 សម្រាប់ការចែកចាយទាំងអស់ ដោយទាញយកតែកញ្ចប់ពីកញ្ចក់លំនាំដើមប៉ុណ្ណោះ។ យើងបានព្រងើយកន្តើយចំពោះកញ្ចប់ដែលមិនមានកម្មវិធី ELF ដែលអាចប្រតិបត្តិបាន ដូចជាប្រភព ពុម្ពអក្សរ។ ការចែកចាយកញ្ចប់ និងឯកសារឆ្លងកាត់ការចែកចាយត្រូវបានបង្ហាញក្នុងរូប។ ៣.

រូបភព។ មួយ

អ្នកអាចសម្គាល់ឃើញថា ការចែកចាយកាន់តែទំនើប កញ្ចប់ និងប្រព័ន្ធគោលពីរកាន់តែច្រើន ដែលវាមានឡូជីខល។ ទោះជាយ៉ាងណាក៏ដោយ កញ្ចប់ Ubuntu និង Debian រួមមានប្រព័ន្ធគោលពីរជាច្រើនទៀត (ទាំងម៉ូឌុលដែលអាចប្រតិបត្តិបាន និងថាមវន្ត និងបណ្ណាល័យ) ជាង CentOS, SUSE និង RHEL ដែលមានសក្តានុពលប៉ះពាល់ដល់ផ្ទៃវាយប្រហាររបស់ Ubuntu និង Debian (គួរកត់សំគាល់ថាលេខឆ្លុះបញ្ចាំងពីប្រព័ន្ធគោលពីរនៃកំណែទាំងអស់ កញ្ចប់ ពោលគឺឯកសារខ្លះត្រូវបានវិភាគច្រើនដង)។ នេះមានសារៈសំខាន់ជាពិសេសនៅពេលអ្នកពិចារណាលើភាពអាស្រ័យរវាងកញ្ចប់។ ដូច្នេះ ភាពងាយរងគ្រោះនៅក្នុងប្រព័ន្ធគោលពីរកញ្ចប់តែមួយអាចប៉ះពាល់ដល់ផ្នែកជាច្រើននៃប្រព័ន្ធអេកូ ដូចជាបណ្ណាល័យដែលងាយរងគ្រោះអាចប៉ះពាល់ដល់ប្រព័ន្ធគោលពីរទាំងអស់ដែលនាំចូលវា។ ជាចំណុចចាប់ផ្តើម សូមក្រឡេកមើលការចែកចាយនៃចំនួនភាពអាស្រ័យក្នុងចំណោមកញ្ចប់នៅក្នុងប្រព័ន្ធប្រតិបត្តិការផ្សេងៗគ្នា៖

រូបភព។ មួយ

នៅក្នុងការចែកចាយស្ទើរតែទាំងអស់ 60% នៃកញ្ចប់មានយ៉ាងហោចណាស់ 10 ភាពអាស្រ័យ។ លើសពីនេះ កញ្ចប់ខ្លះមានចំនួនច្រើននៃភាពអាស្រ័យ (ច្រើនជាង 100)។ អនុវត្តដូចគ្នាចំពោះភាពអាស្រ័យនៃកញ្ចប់បញ្ច្រាស៖ ដូចដែលបានរំពឹងទុក កញ្ចប់មួយចំនួនត្រូវបានប្រើប្រាស់ដោយកញ្ចប់ផ្សេងទៀតជាច្រើនក្នុងការចែកចាយ ដូច្នេះភាពងាយរងគ្រោះក្នុងជម្រើសមួយចំនួនមានហានិភ័យខ្ពស់។ ជាឧទាហរណ៍ តារាងខាងក្រោមរាយបញ្ជីកញ្ចប់ចំនួន 20 ដែលមានចំនួនអតិបរមានៃភាពអាស្រ័យបញ្ច្រាសនៅក្នុង SLES, Centos 7, Debian 9 និង Ubuntu 18.04 (ក្រឡានីមួយៗបង្ហាញពីកញ្ចប់ និងចំនួននៃការពឹងផ្អែកបញ្ច្រាស)។

តារាង 3

ការពិតគួរឱ្យចាប់អារម្មណ៍។ ទោះបីជាប្រព័ន្ធប្រតិបត្តិការទាំងអស់ដែលបានវិភាគត្រូវបានបង្កើតឡើងសម្រាប់ស្ថាបត្យកម្ម x86_64 ហើយកញ្ចប់ភាគច្រើនមានស្ថាបត្យកម្មដែលបានកំណត់ជា x86_64 និង x86 កញ្ចប់ជាញឹកញាប់មានប្រព័ន្ធគោលពីរសម្រាប់ស្ថាបត្យកម្មផ្សេងទៀតដូចដែលបានបង្ហាញក្នុងរូបភាពទី 5 ។ ៥.

រូបភព។ មួយ

នៅផ្នែកបន្ទាប់ យើងនឹងស្វែងយល់អំពីលក្ខណៈនៃគោលពីរដែលបានវិភាគ។

ស្ថិតិការពារឯកសារគោលពីរ

នៅអប្បបរមាដាច់ខាត អ្នកត្រូវស្វែងរកសំណុំជម្រើសសុវត្ថិភាពជាមូលដ្ឋានសម្រាប់ប្រព័ន្ធគោលពីរដែលមានស្រាប់របស់អ្នក។ ការចែកចាយលីនុចជាច្រើនមកជាមួយស្គ្រីបដែលធ្វើការត្រួតពិនិត្យបែបនេះ។ ឧទាហរណ៍ 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: ថាតើជង់ Canaries ត្រូវបានបើកដើម្បីការពារប្រឆាំងនឹងការវាយប្រហារជង់ជង់។
• ប្រភព Fortify៖ ថាតើមុខងារមិនមានសុវត្ថិភាព (ឧទាហរណ៍ strcpy) ត្រូវបានជំនួសដោយសមភាគីដែលមានសុវត្ថិភាពជាងរបស់ពួកគេទេ ហើយការហៅទូរសព្ទដែលបានពិនិត្យនៅពេលដំណើរការត្រូវបានជំនួសដោយសមភាគីដែលមិនបានត្រួតពិនិត្យរបស់ពួកគេ (ឧទាហរណ៍ memcpy ជំនួសឱ្យ __memcpy_chk)។
• ការផ្លាស់ទីលំនៅបានតែអាន (RELRO)៖ ថាតើធាតុតារាងផ្លាស់ប្តូរទីតាំងត្រូវបានសម្គាល់ថាអានបានតែប្រសិនបើវាត្រូវបានកេះមុនពេលចាប់ផ្តើមប្រតិបត្តិការ។
• ការចងភ្លាមៗ៖ ថាតើកម្មវិធីភ្ជាប់ពេលដំណើរការអនុញ្ញាតឱ្យផ្លាស់ទីទាំងអស់ មុនពេលការប្រតិបត្តិកម្មវិធីចាប់ផ្តើម (វាស្មើនឹង RELRO ពេញលេញ)។

តើយន្តការខាងលើគ្រប់គ្រាន់ទេ? ជាអកុសលទេ។ មានវិធីដែលគេស្គាល់ដើម្បីជៀសផុតពីការការពារទាំងអស់ខាងលើ ប៉ុន្តែការការពារកាន់តែតឹងរ៉ឹង របារសម្រាប់អ្នកវាយប្រហារកាន់តែខ្ពស់។ ឧទាហរណ៍, វិធីសាស្រ្តឆ្លងកាត់ RELRO កាន់តែលំបាកក្នុងការអនុវត្ត ប្រសិនបើ PIE និងការចងជាបន្ទាន់មានប្រសិទ្ធភាព។ ដូចគ្នានេះដែរ ASLR ពេញលេញទាមទារការងារបន្ថែមដើម្បីបង្កើតការកេងប្រវ័ញ្ចការងារ។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកវាយប្រហារដ៏ទំនើបត្រូវបានរៀបចំរួចរាល់ហើយដើម្បីបំពេញការការពារបែបនេះ៖ អវត្តមានរបស់ពួកគេនឹងបង្កើនល្បឿនការ hack យ៉ាងសំខាន់។ ដូច្នេះវាចាំបាច់ណាស់ដែលវិធានការទាំងនេះត្រូវបានចាត់ទុកថាចាំបាច់ អប្បបរមា.

យើងចង់សិក្សាថាតើឯកសារប្រព័ន្ធគោលពីរប៉ុន្មាននៅក្នុងការចែកចាយដែលមានសំណួរត្រូវបានការពារដោយវិធីទាំងនេះ និងវិធីបីផ្សេងទៀត៖

• ប៊ីតដែលមិនអាចប្រតិបត្តិបាន (NX) ការពារការប្រតិបត្តិក្នុងផ្នែកណាមួយដែលមិនគួរប្រតិបត្តិ ដូចជា stack heap ជាដើម។
• RPATH/រត់ប៉ាត សម្គាល់ផ្លូវប្រតិបត្តិដែលប្រើដោយកម្មវិធីផ្ទុកថាមវន្ត ដើម្បីស្វែងរកបណ្ណាល័យដែលត្រូវគ្នា។ ទីមួយគឺ ជាកាតព្វកិច្ច សម្រាប់ប្រព័ន្ធទំនើបណាមួយ៖ អវត្ដមានរបស់វាអនុញ្ញាតឱ្យអ្នកវាយប្រហារអាចសរសេរបន្ទុកទៅក្នុងអង្គចងចាំតាមអំពើចិត្ត ហើយប្រតិបត្តិវាតាមអំពើចិត្ត។ សម្រាប់ទីពីរ ការកំណត់រចនាសម្ព័ន្ធផ្លូវប្រតិបត្តិមិនត្រឹមត្រូវជួយក្នុងការណែនាំកូដដែលមិនគួរឱ្យទុកចិត្តដែលអាចនាំឱ្យមានបញ្ហាមួយចំនួន (ឧ. ការកើនឡើងឯកសិទ្ធិ, ក៏ដូចជា បញ្ហាផ្សេងៗ).
• ការការពារការប៉ះទង្គិចគ្នាជាជង់ផ្តល់ការការពារប្រឆាំងនឹងការវាយប្រហារដែលបណ្តាលឱ្យជង់ត្រួតលើតំបន់ផ្សេងទៀតនៃអង្គចងចាំ (ដូចជាហ៊ា)។ ការ​កេង​ប្រវ័ញ្ច​ថ្មីៗ​ដែល​បាន​ផ្តល់​ឱ្យ​ដោយ​បំពាន ភាពងាយរងគ្រោះនៃការប៉ះទង្គិចគ្នាជាប្រព័ន្ធយើងមានអារម្មណ៍ថាវាសមស្របក្នុងការបញ្ចូលយន្តការនេះនៅក្នុងសំណុំទិន្នន័យរបស់យើង។

ដូច្នេះ បើ​មិន​ចាំ​បាច់​ទៀត​ទេ ចូរ​ចុះ​ដល់​លេខ។ តារាងទី 4 និងទី 5 មានសេចក្តីសង្ខេបនៃការវិភាគនៃឯកសារដែលអាចប្រតិបត្តិបាន និងបណ្ណាល័យនៃការចែកចាយផ្សេងៗរៀងៗខ្លួន។

• ដូចដែលអ្នកអាចឃើញការការពារ NX ត្រូវបានអនុវត្តនៅគ្រប់ទីកន្លែងដោយមានករណីលើកលែងដ៏កម្រ។ ជាពិសេស មនុស្សម្នាក់អាចកត់សម្គាល់ការប្រើប្រាស់របស់វាទាបជាងបន្តិចនៅក្នុងការចែកចាយ Ubuntu និង Debian បើប្រៀបធៀបទៅនឹង CentOS, RHEL និង OpenSUSE ។
• ជង់ Canaries ត្រូវបានបាត់នៅកន្លែងជាច្រើន ជាពិសេសនៅក្នុងការចែកចាយជាមួយខឺណែលចាស់ៗ។ វឌ្ឍនភាពមួយចំនួនត្រូវបានគេមើលឃើញនៅក្នុងការចែកចាយចុងក្រោយបំផុតនៃ 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 (ការអនុវត្តមុខងារពាក់ព័ន្ធគិតជាភាគរយនៃចំនួនបណ្ណាល័យសរុប)

ដូច្នេះតើមានការរីកចម្រើនទេ? ពិតជាមាន៖ នេះអាចមើលឃើញពីស្ថិតិសម្រាប់ការចែកចាយបុគ្គល (ឧទាហរណ៍ ដេបៀន) ក៏ដូចជាពីតារាងខាងលើ។ ជាឧទាហរណ៍ក្នុងរូប។ រូបភាពទី 6 បង្ហាញពីការអនុវត្តយន្តការការពារនៅក្នុងការចែកចាយបន្តបន្ទាប់ចំនួនបីនៃ Ubuntu LTS 5 (យើងបានលុបចោលស្ថិតិការពារការប៉ះទង្គិចគ្នាជាជង់)។ យើងកត់សំគាល់ថាពីកំណែមួយទៅកំណែឯកសារកាន់តែច្រើនគាំទ្រជង់ Canaries ហើយប្រព័ន្ធគោលពីរកាន់តែច្រើនត្រូវបានដឹកជញ្ជូនជាមួយនឹងការការពារ RELRO ពេញលេញ។

រូបភព។ មួយ

ជាអកុសល ឯកសារដែលអាចប្រតិបត្តិបានមួយចំនួននៅក្នុងការចែកចាយផ្សេងៗគ្នានៅតែមិនមានការការពារខាងលើ។ ឧទាហរណ៍ ក្រឡេកមើល Ubuntu 18.04 អ្នកនឹងសម្គាល់ឃើញ ngetty binary (ការជំនួស getty) ក៏ដូចជា mksh និង lksh shells អ្នកបកប្រែ picolisp កញ្ចប់ nvidia-cuda-toolkit (កញ្ចប់ពេញនិយមសម្រាប់កម្មវិធី GPU-accelerated ដូចជា ក្របខណ្ឌសិក្សាម៉ាស៊ីន) និង klibc -utils ។ ដូចគ្នានេះដែរ ប្រព័ន្ធគោលពីរ mandos-client (ឧបករណ៍រដ្ឋបាលដែលអនុញ្ញាតឱ្យអ្នកចាប់ផ្តើមម៉ាស៊ីនឡើងវិញដោយស្វ័យប្រវត្តិជាមួយនឹងប្រព័ន្ធឯកសារដែលបានអ៊ិនគ្រីប) ក៏ដូចជា rsh-redone-client (ការអនុវត្តឡើងវិញនៃ rsh និង rlogin) ដោយគ្មានការការពារ NX ទោះបីជាពួកគេមានសិទ្ធិ SUID ក៏ដោយ៖ (។ ផងដែរ ប្រព័ន្ធគោលពីរ suid ជាច្រើនខ្វះការការពារជាមូលដ្ឋានដូចជា stack canaries (ឧទាហរណ៍ Xorg.wrap binary ពីកញ្ចប់ 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, ខ្លា, Hubble) ដែលអនុវត្តការវិភាគ និងជួយជៀសវាងការកំណត់រចនាសម្ព័ន្ធដែលមិនមានសុវត្ថិភាព។ ជាអកុសល សូម្បីតែការការពារដ៏រឹងមាំនៅក្នុងការកំណត់រចនាសម្ព័ន្ធសមហេតុផលក៏មិនធានាអវត្តមាននៃការកេងប្រវ័ញ្ចដែរ។ នោះហើយជាមូលហេតុដែលយើងជឿជាក់យ៉ាងមុតមាំថាវាមានសារៈសំខាន់ណាស់ក្នុងការធានា ការត្រួតពិនិត្យ និងការការពារដែលអាចទុកចិត្តបាននៃការវាយប្រហារក្នុងពេលវេលាជាក់ស្តែងដោយផ្តោតលើគំរូនៃការកេងប្រវ័ញ្ច និងទប់ស្កាត់ពួកគេ។

ប្រភព: www.habr.com