ប៉ុស្តិ៍ត្រួតពិនិត្យបានស្នើឡើងនូវបច្ចេកទេសការពារ Safe-Linking ដែលធ្វើឱ្យវាកាន់តែពិបាកក្នុងការទាញយកភាពងាយរងគ្រោះ

ក្រុមហ៊ុនត្រួតពិនិត្យ បង្ហាញ យន្តការការពារ Safe-Linking ដែលធ្វើឱ្យវាពិបាកក្នុងការបង្កើតការកេងប្រវ័ញ្ចដែលរៀបចំនិយមន័យ ឬការកែប្រែចំណុចចង្អុលទៅសតិបណ្ដោះអាសន្នដែលបានបម្រុងទុកនៅពេលដំណើរការការហៅទូរសព្ទ malloc។ Safe-Linking មិនរារាំងទាំងស្រុងនូវលទ្ធភាពនៃការកេងប្រវ័ញ្ចភាពងាយរងគ្រោះនោះទេ ប៉ុន្តែជាមួយនឹងការចំណាយតិចតួចបំផុត វាធ្វើឱ្យមានភាពស្មុគស្មាញយ៉ាងខ្លាំងដល់ការបង្កើតប្រភេទមួយចំនួននៃការកេងប្រវ័ញ្ច ដោយសារបន្ថែមពីលើការហៀរសំបោរដែលអាចកេងប្រវ័ញ្ចបាន វាចាំបាច់ក្នុងការស្វែងរកភាពងាយរងគ្រោះផ្សេងទៀតដែលបណ្តាលឱ្យលេចធ្លាយព័ត៌មានអំពី ការដាក់គំនរនៅក្នុងការចងចាំ។

បំណះដែលអនុវត្ត Safe-Linking ត្រូវបានរៀបចំសម្រាប់ Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) និង Google TCMalloc ហើយក៏ត្រូវបានស្នើឡើងសម្រាប់ការធ្វើឱ្យប្រសើរឡើងនូវការការពារនៅក្នុង Chromium (នៅក្នុង
ចាប់តាំងពីឆ្នាំ 2012 Chromium បានសាងសង់រួចហើយនៅក្នុងបច្ចេកទេសការពារ MaskPtr ក្នុងគោលបំណងដោះស្រាយបញ្ហាដូចគ្នា ប៉ុន្តែដំណោះស្រាយពី Checkpoint បង្ហាញពីដំណើរការខ្ពស់ជាង)។
បំណះដែលបានណែនាំត្រូវបានអនុម័តរួចហើយសម្រាប់ការចែកចាយនៅក្នុងការចេញផ្សាយខែសីហា Glibc ២.៣០ ហើយ Safe-Linking នឹងត្រូវបានបើកតាមលំនាំដើម។ uCibc-NG គាំទ្រ Safe-Linking បានបញ្ចូល រួមបញ្ចូលនៅក្នុងការចេញផ្សាយ 1.0.33 ហើយត្រូវបានបើកតាមលំនាំដើម។ ការផ្លាស់ប្តូរនៅក្នុង gperftools (tcmalloc ចាស់) ទទួលយកប៉ុន្តែនឹងត្រូវបានផ្តល់ជូនជាជម្រើសមួយនៅក្នុងការចេញផ្សាយនាពេលខាងមុខ។

អ្នកអភិវឌ្ឍន៍ TCMalloc (tcmalloc ថ្មី) បដិសេធមិនទទួលយក ការផ្លាស់ប្តូរដោយលើកឡើងពីការថយចុះនៃការអនុវត្តធ្ងន់ធ្ងរ និងតម្រូវការក្នុងការបន្ថែមការធ្វើតេស្តយ៉ាងទូលំទូលាយ ដើម្បីត្រួតពិនិត្យជាប្រចាំថាអ្វីៗដំណើរការដូចការរំពឹងទុក។ ការធ្វើតេស្តដោយវិស្វករ Checkpoint បានបង្ហាញថាវិធីសាស្ត្រ Safe-Linking មិននាំឱ្យមានការប្រើប្រាស់អង្គចងចាំបន្ថែមទេ ហើយការអនុវត្តនៅពេលអនុវត្តប្រតិបត្តិការ heap ត្រូវបានកាត់បន្ថយជាមធ្យមត្រឹមតែ 0.02% ហើយក្នុងករណីដ៏អាក្រក់បំផុតគឺ 1.5% (សម្រាប់ការប្រៀបធៀប ការចំណាយលើសនៅក្នុង វិធីសាស្ត្រដែលប្រើក្នុង Chromium ត្រូវបានប៉ាន់ប្រមាណថា "តិចជាង 2%")។ ការដាក់បញ្ចូល
Safe-Linking លទ្ធផលនៅក្នុងការណែនាំបន្ថែម 2-3 ត្រូវបានប្រតិបត្តិរាល់ពេលដែល free() ត្រូវបានហៅ ហើយការណែនាំ 3-4 រាល់ពេលដែល malloc() ត្រូវបានហៅ។ ការដំណើរការដំណាក់កាលបង្កើតតម្លៃដំបូង និងចៃដន្យមិនត្រូវបានទាមទារទេ។

Safe-Linking អាចត្រូវបានប្រើមិនត្រឹមតែដើម្បីធ្វើឱ្យប្រសើរឡើងនូវសុវត្ថិភាពនៃការអនុវត្ត heap ផ្សេងៗប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងបន្ថែមការគ្រប់គ្រងសុចរិតភាពទៅរចនាសម្ព័ន្ធទិន្នន័យណាមួយដែលប្រើបញ្ជីចង្អុលដែលភ្ជាប់តែមួយដែលដាក់នៅជាប់នឹងសតិបណ្ដោះអាសន្នខ្លួនឯង។ វិធីសាស្រ្តនេះគឺសាមញ្ញណាស់ក្នុងការអនុវត្ត ហើយគ្រាន់តែតម្រូវឱ្យបន្ថែមម៉ាក្រូមួយ ហើយអនុវត្តវាទៅចង្អុលទៅប្លុកបន្ទាប់នៅក្នុងកូដ (ឧទាហរណ៍សម្រាប់ Glibc ការផ្លាស់ប្តូរ កូដពីរបីបន្ទាត់) ។ វិធី​សា​ស្រ្ត​ពុះ​កញ្ជ្រោល​ទៅ​នឹង​ការ​ផ្លាស់​ប្តូ​រ​ដូច​ខាង​ក្រោម​:

+#កំណត់ PROTECT_PTR(pos, ptr) \\
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- បន្ទាប់ = p->fd;
+ បន្ទាប់ = REVEAL_PTR (p->fd);
...

ខ្លឹមសារនៃវិធីសាស្ត្រគឺត្រូវប្រើទិន្នន័យចៃដន្យពីយន្តការចៃដន្យអាសយដ្ឋាន ASLR (mmap_base) ដើម្បីការពារបញ្ជីដែលភ្ជាប់តែមួយដូចជា Fast-Bins និង TCache ។ មុនពេលតម្លៃត្រូវបានអនុវត្តចំពោះទ្រនិចទៅធាតុបន្ទាប់នៅក្នុងបញ្ជី វាដំណើរការការបំប្លែងរបាំង និងពិនិត្យមើលការតម្រឹមទំព័រ។ ទ្រនិចត្រូវបានជំនួសដោយលទ្ធផលនៃប្រតិបត្តិការ "(L>> PAGE_SHIFT) XOR (P)" ដែល P ជាតម្លៃនៃទ្រនិច ហើយ L គឺជាទីតាំងអង្គចងចាំដែលទ្រនិចត្រូវបានរក្សាទុក។

នៅពេលប្រើក្នុងប្រព័ន្ធ ASLR (Address Space Layout Randomization) ជាផ្នែកនៃ L bits ជាមួយ heap base address មានតម្លៃចៃដន្យដែលប្រើជា key ដើម្បី encode P (ដកស្រង់ដោយ 12-bit shift operations for 4096-byte pages)។ ឧបាយកលនេះកាត់បន្ថយហានិភ័យនៃការលួចទ្រនិចក្នុងការកេងប្រវ័ញ្ច ដោយសារទ្រនិចមិនត្រូវបានរក្សាទុកក្នុងទម្រង់ដើមរបស់វា ហើយការជំនួសវាទាមទារចំណេះដឹងអំពីការបែងចែកហ៊ា។ លើសពីនេះ កូដបំណះក៏មានការត្រួតពិនិត្យបន្ថែមសម្រាប់ការតម្រឹមប្លុក ដែលមិនអនុញ្ញាតឱ្យអ្នកវាយប្រហារជំនួសទ្រនិចដោយតម្លៃមិនតម្រឹម និងទាមទារចំណេះដឹងអំពីចំនួនប៊ីតដែលត្រូវបានតម្រឹម ដែលនៅលើប្រព័ន្ធ 64 ប៊ីត អនុញ្ញាតបន្ថែមការទប់ស្កាត់។ ការប៉ុនប៉ងវាយប្រហារចំនួន 15 ក្នុងចំណោម 16 ដែលមិនគិតពីការតម្រឹមក្នុងគណនី។

វិធីសាស្ត្រនេះមានប្រសិទ្ធភាពសម្រាប់ការពារប្រឆាំងនឹងការវាយប្រហារដែលប្រើការសរសេរទ្រនិចមួយផ្នែកឡើងវិញ (ផ្លាស់ប្តូរបៃទាប) ការសរសេរទ្រនិចពេញលេញឡើងវិញ (ការបញ្ជូនបន្តទៅកាន់កូដរបស់អ្នកវាយប្រហារ) និងការផ្លាស់ប្តូរទីតាំងបញ្ជីនៅអាសយដ្ឋានមិនតម្រឹម។ ជាឧទាហរណ៍ វាត្រូវបានបង្ហាញថាការប្រើប្រាស់ Safe-Linking នៅក្នុង malloc នឹងអនុញ្ញាតឱ្យមានការទប់ស្កាត់ការកេងប្រវ័ញ្ចនាពេលថ្មីៗនេះ កំណត់អត្តសញ្ញាណ ដោយអ្នកស្រាវជ្រាវភាពងាយរងគ្រោះដូចគ្នា។ CVE-2020-6007 នៅក្នុងអំពូលភ្លើងឆ្លាតវៃ Philips Hue Bridge ដែលបណ្តាលមកពីការហៀរសំបោរ និងអនុញ្ញាតឱ្យអ្នកទទួលបានការគ្រប់គ្រងឧបករណ៍។

ប្រភព: opennet.ru