Glibc រួមបញ្ចូលការជួសជុលសម្រាប់ភាពងាយរងគ្រោះ memcpy ដែលរៀបចំដោយអ្នកអភិវឌ្ឍន៍ Aurora OS

អ្នកបង្កើតប្រព័ន្ធប្រតិបត្តិការទូរស័ព្ទចល័ត Aurora (ចំនុចប្រសព្វនៃ Sailfish OS ដែលបង្កើតឡើងដោយក្រុមហ៊ុន Open Mobile Platform) បានចែករំលែករឿងរ៉ាវដែលបង្ហាញពីការលុបបំបាត់ ភាពងាយរងគ្រោះសំខាន់ (CVE-2020-6096) នៅក្នុង Glibc ដែលបង្ហាញតែនៅលើវេទិកា ARMv7 ប៉ុណ្ណោះ។ ព័ត៌មានអំពីភាពងាយរងគ្រោះត្រូវបានលាតត្រដាងកាលពីខែឧសភា ប៉ុន្តែរហូតមកដល់ប៉ុន្មានថ្ងៃចុងក្រោយនេះ ការជួសជុលមិនអាចរកបានទេ ទោះបីជាមានភាពងាយរងគ្រោះក៏ដោយ ចាត់តាំង កម្រិតខ្ពស់នៃគ្រោះថ្នាក់ ហើយមានគំរូការងារនៃការកេងប្រវ័ញ្ចដែលអនុញ្ញាតឱ្យអ្នករៀបចំការប្រតិបត្តិកូដនៅពេលដំណើរការទិន្នន័យដែលបានធ្វើទ្រង់ទ្រាយតាមវិធីជាក់លាក់មួយនៅក្នុងមុខងារ memcpy() និង memmove() ។ កញ្ចប់ជួសជុលសម្រាប់ ដេបៀន и គូប៊ុនទូ មិនទាន់ត្រូវបានចេញផ្សាយនៅឡើយទេ និងភាពងាយរងគ្រោះនៅតែមិនទាន់ជួសជុលអស់រយៈពេលជិតពីរខែចាប់ពីពេលនៃការបង្ហាញជាសាធារណៈ និង XNUMX ខែចាប់ពីពេលដែលអ្នកអភិវឌ្ឍន៍ Glibc ត្រូវបានជូនដំណឹង។

ភាពងាយរងគ្រោះត្រូវបានបង្ហាញដោយខ្លួនវាផ្ទាល់នៅក្នុងការអនុវត្ត memcpy() និង memmove() ជាភាសាដំឡើងសម្រាប់ ARMv7 ហើយត្រូវបានបង្កឡើងដោយដំណើរការមិនត្រឹមត្រូវនៃតម្លៃអវិជ្ជមាននៃប៉ារ៉ាម៉ែត្រដែលកំណត់ទំហំនៃផ្ទៃដែលបានចម្លង។ បញ្ហាជាមួយការអភិវឌ្ឍន៍បំណះបានចាប់ផ្តើមនៅពេលដែលក្រុមហ៊ុននានា ស៊ូស៊ី и Red Hat បានប្រកាសថាវេទិការបស់ពួកគេមិនត្រូវបានប៉ះពាល់ដោយបញ្ហានោះទេ ចាប់តាំងពីពួកគេមិនបានបង្កើតសម្រាប់ប្រព័ន្ធ 32-bit ARMv7 ហើយមិនបានចូលរួមក្នុងការបង្កើតការជួសជុលនោះទេ។ អ្នកអភិវឌ្ឍន៍នៃការចែកចាយដែលបានបង្កប់ជាច្រើនហាក់ដូចជាពឹងផ្អែកលើក្រុម Glibc ហើយក៏មិនបានចូលរួមយ៉ាងសកម្មក្នុងការរៀបចំការជួសជុលនេះដែរ។

ជម្រើស។ បំណះ ដើម្បីទប់ស្កាត់បញ្ហា ក្រុមហ៊ុន Huawei ស្ទើរតែភ្លាមៗបានស្នើថា ខ្លួនព្យាយាមជំនួសការណែនាំការជួបប្រជុំគ្នាដែលដំណើរការជាមួយ operands ដែលបានចុះហត្ថលេខា (bge និង blt) ជាមួយនឹង analogues ដែលមិនចុះហត្ថលេខា (blo និង bhs) ។ អ្នកថែទាំ glibc បានបង្កើតសំណុំនៃការធ្វើតេស្តដើម្បីពិនិត្យមើលលក្ខខណ្ឌកំហុសផ្សេងៗ បន្ទាប់ពីនោះវាបានប្រែក្លាយថាបំណះ Huawei មិនសមរម្យ និងមិនបានដំណើរការបន្សំដែលអាចធ្វើបានទាំងអស់នៃទិន្នន័យបញ្ចូល។

ដោយសារ Aurora OS មាន 32-bit build សម្រាប់ ARM អ្នកអភិវឌ្ឍន៍របស់ខ្លួនបានសម្រេចចិត្តបិទភាពងាយរងគ្រោះដោយខ្លួនឯង ហើយផ្តល់ដំណោះស្រាយដល់សហគមន៍។ ការលំបាកនោះគឺថា វាចាំបាច់ក្នុងការសរសេរការអនុវត្តភាសាសភាប្រកបដោយប្រសិទ្ធភាពនៃមុខងារ និងគិតគូរពីជម្រើសផ្សេងៗសម្រាប់អាគុយម៉ង់បញ្ចូល។ ការអនុវត្តត្រូវបានសរសេរឡើងវិញដោយប្រើការណែនាំដែលមិនបានចុះហត្ថលេខា។ បំណះ វាប្រែជាតូច ប៉ុន្តែបញ្ហាចម្បងគឺការរក្សាបាននូវល្បឿនប្រតិបត្តិ និងជៀសវាងការថយចុះនៃដំណើរការនៃមុខងារ memcpy និង memmove ខណៈពេលដែលរក្សាបាននូវភាពឆបគ្នាជាមួយនឹងបន្សំនៃតម្លៃបញ្ចូលទាំងអស់។

នៅដើមខែមិថុនា កំណែចំនួនពីរនៃការជួសជុលត្រូវបានរៀបចំឡើង ដោយឆ្លងកាត់ក្របខ័ណ្ឌសាកល្បងរបស់អ្នកថែទាំ Glibc និងឈុតសាកល្បងខាងក្នុងរបស់ Aurora ។ នៅថ្ងៃទី 3 ខែមិថុនាជម្រើសមួយក្នុងចំណោមជម្រើសត្រូវបានជ្រើសរើសនិង បានផ្ញើ ទៅកាន់បញ្ជីសំបុត្ររួមរបស់ Glibc ។ មួយសប្តាហ៍ក្រោយមក
គឺ បានស្នើឡើង បំណះមួយផ្សេងទៀតដែលស្រដៀងគ្នានៅក្នុងវិធីសាស្រ្តដែលបានកែបញ្ហានៅក្នុងការអនុវត្ត multiarch ដែលក្រុមហ៊ុន Huawei បានព្យាយាមជួសជុលពីមុន។ ការធ្វើតេស្តចំណាយពេលមួយខែ ការចុះឈ្មោះស្របច្បាប់ ដោយសារតែសារៈសំខាន់នៃបំណះ។
ការកែតម្រូវថ្ងៃទី 8 ខែកក្កដា ត្រូវបានទទួលយក ទៅកាន់សាខាសំខាន់នៃការចេញផ្សាយ glibc 2.32 នាពេលខាងមុខ។ ការអនុវត្តរួមមានបំណះពីរ − первый សម្រាប់ការអនុវត្ត multiarch នៃ memcpy សម្រាប់ ARMv7 និង ទីពីរ សម្រាប់ការអនុវត្តភាសាសន្និបាតទូទៅនៃ memcpy() និង memmove() សម្រាប់ ARM ។

បញ្ហាប៉ះពាល់ដល់ឧបករណ៍ ARMv7 រាប់លានដែលកំពុងដំណើរការលីនុច ហើយបើគ្មានការអាប់ដេតសមស្របទេ ម្ចាស់មានហានិភ័យនៅពេលភ្ជាប់ពួកវាទៅបណ្តាញ (សេវាដែលអាចចូលប្រើបណ្តាញ និងកម្មវិធីដែលទទួលយកទិន្នន័យបញ្ចូលដោយគ្មានការរឹតបន្តឹងទំហំអាចត្រូវបានវាយប្រហារ)។ ជាឧទាហរណ៍ ការកេងប្រវ័ញ្ចដែលរៀបចំដោយអ្នកស្រាវជ្រាវដែលបានកំណត់អត្តសញ្ញាណភាពងាយរងគ្រោះបង្ហាញពីរបៀបវាយប្រហារម៉ាស៊ីនមេ HTTP ដែលបានបង្កើតឡើងនៅក្នុងប្រព័ន្ធព័ត៌មានរថយន្តដោយផ្ញើសំណើរ GET ដ៏ធំមួយ និងទទួលបានសិទ្ធិជា root ទៅកាន់ប្រព័ន្ធ។

ប្រភព: opennet.ru