AuroraOS mobilās operētājsistēmas izstrādātāji (operētājsistēmas Sailfish dakša, ko izstrādājusi kompānija Open Mobile Platform) kopīgoja ievainojamības labojumu ko viņi atklāja memcpy. Kritiskās neaizsargātības novēršana (CVE-2020-6096) Glibcā, kas izpaužas tikai ARMv7 platformā.
Informācija par ievainojamību tika atklāta maijā, bet līdz pēdējām dienām labojumi nebija pieejami, neskatoties uz to, ka ievainojamībai tika piešķirts augsts bīstamības līmenis un ir darbojošs ekspluatācijas prototips kas ļauj organizēt koda izpildi.
Izmantošana sagatavota darbojas apstrādes laikā funkcijās memcpy () un memmove () noteiktiem formatētiem datiem.
Glibc nozīme ir tā, ka šajā bibliotēkā papildus sistēmas izmanto gandrīz visas programmas, tiek definēti sistēmas izsaukumi un citas pamatfunkcijas.
Par problēmu
Ievainojamība izpaudās memcpy () un memmove () ieviešanā ARMv7 montāžas valodā un to izraisīja nepareiza parametra negatīvo vērtību apstrāde, kas nosaka laukuma lielumu.
Sākās problēmas ar plākstera izstrādi kad SUSE un Red Hat paziņoja, ka viņu platformas netiek ietekmētas problēmas dēļ, jo tie neapkopoja 7 bitu ARMv32 sistēmas un nepiedalījās plākstera izveidē.
Daudzu iegulto izplatītāju izstrādātāji acīmredzot uzticējās Glibc komandai, un viņi arī aktīvi nepiedalījās plākstera sagatavošanā.
risinājumi
Huawei piedāvāja iespēju par plāksteri gandrīz nekavējoties bloķēt problēmu, kas mēģināja aizstāt montētāja instrukcijas, kas darbojas ar parakstītiem operandiem (bge un blt), ar neparakstītiem analogiem (blo un bhs).
Glibc uzturētāji izstrādāja testa komplektu pārbaudīt dažādus kļūdas rašanās apstākļus pēc kas izrādījās, ka Huawei plāksteris neder un tas neapstrādā visas iespējamās ievades datu kombinācijas.
Kopš tā laika AuroraOS ir izveidots 32 bitu ARM, tā izstrādātāji nolēma patstāvīgi slēgt ievainojamību un ierosināt kopienai risinājumu.
Grūtības bija tādas, ka bija nepieciešams uzrakstīt efektīvu ieviešanu assembler un apsveriet vairākas ievades argumentu iespējas.
Ieviešana ir pārrakstīta, izmantojot neparakstītas instrukcijas. Plāksteris izrādījās mazs, taču galvenā problēma bija izpildes ātruma uzturēšana un veiktspējas pasliktināšanās novēršana no memcpy un memmove funkcijām, vienlaikus saglabājot saderību ar visām ievades vērtību kombinācijām.
Jūnija sākumā tika sagatavoti divi risinājumi, nokārtojot Glibca tehniskās apkopes testu sistēmu un Aurora iekšējo testu komplektu. 3. jūnijā tika izvēlēts un iesniegts viens no variantiem uz Glibc adresātu sarakstu.
Pēc nedēļas tika piedāvāta vēl viena līdzīga pieeja, kas novērsa multiarha ieviešanas problēmu, kuru Huawei iepriekš bija mēģinājis novērst. Mēnesi ilga testēšana un legalizācija, ņemot vērā plākstera nozīmi.
8. jūlijā labojumi tika pieņemti galvenajā filiālē gaidāmā glibc 2.32 izlaiduma. Pieteikumā ir divi plāksteri:
- Pirmais atmiņas izveides multiarh lietojumprogrammai ARMv7
- Otrais par kopīgu montētāja ieviešanu memcpy () un memmove () ARM.
Problēma ietekmē miljoniem ARMv7 Linux ierīču un bez pienācīgas atjaunināšanas īpašnieki riskē tos savienot ar tīklu (var tikt uzbrukts tīklā pieejamiem pakalpojumiem un lietojumprogrammām, kas pieņem ievadi bez lieluma ierobežojumiem).
Piemēram, sagatavots darbs pētnieki, kuri atklāja, ka ievainojamība parāda, kā uzbrukt http serverim integrēta automašīnas informācijas sistēmā, pārsūtot ļoti lielu GET pieprasījumu un iegūstot root piekļuvi sistēmai.
Debian un Ubuntu pakotņu risinājumi vēl nav izlaisti y ievainojamība joprojām nav labota gandrīz divus mēnešus no publiskošanas brīža un piecus mēnešus no brīža, kad tika paziņots Glibc izstrādātājiem.