Распрацоўнікі мабільнай аперацыйнай сістэмы «Аўрора» (форк АС Sailfish, які развіваецца кампаніяй «Адкрытая мабільная платформа») падзяліліся паказальнай гісторыяй аб ухіленні () у Glibc, якая праяўляецца толькі на платформе ARMv7. Звесткі аб уразлівасці былі раскрыты яшчэ ў маі, але да апошніх дзён выпраўлення не былі даступныя, нягледзячы на тое, што ўразлівасці высокі ўзровень небяспекі і маецца працоўны прататып эксплоіту, які дазваляе арганізаваць выкананне кода пры апрацоўцы ў функцыях memcpy() і memmove() вызначанай выявай аформленых дадзеных. Выпраўленні пакетаў для и не выпушчаныя да гэтага часу і ўразлівасць застаецца нявыпраўленай амаль два месяцаў з моманту публічнага расчынення і пяць месяцаў з моманту апавяшчэння распрацоўнікаў Glibc.
Уразлівасць выяўлялася ў рэалізацыі memcpy() і memmove() на мове асэмблера для ARMv7 і была выкліканая некарэктнай апрацоўкай адмоўных значэнняў параметру, вызначальнага памер якая капіюецца вобласці. Праблемы з распрацоўкай патчаў пачаліся з таго, што кампаніі и абвясцілі, што іх платформы праблеме не схільныя, бо яны не фармуюць зборкі для 32-разрадных сістэм ARMv7, і не сталі ўдзельнічаць у стварэнні выпраўлення. Распрацоўнікі шматлікіх убудаваных дыстрыбутываў, мабыць, паклаліся на каманду Glibc, і таксама не выявілі актыўнага ўдзелу ў падрыхтоўцы выпраўлення.
варыянт для блакавання праблемы амаль адразу прапанавала кампанія Huawei, якая паспрабавала замяніць асэмблерныя інструкцыі, якія аперуюць знакавымі аперандамі (bge і blt), на беззнакавыя аналагі (blo і bhs). Мэйнтэнеры Glibc распрацавалі набор тэстаў для праверкі розных умоў узнікнення памылкі, пасля чаго высветлілася, што патч ад Huawei не падыходзіць і не апрацоўвае ўсе магчымыя камбінацыі ўваходных дадзеных.
Бо АС Аўрора мае 32-бітную зборку для ARM, яе распрацоўнікі вырашылі зачыніць уразлівасць саматугам і прапанаваць рашэнне супольнасці. Складанасць заключалася ў тым, што трэба было напісаць эфектыўную асэмблерную рэалізацыю функцыі і ўлічыць пры гэтым розныя варыянты ўваходных аргументаў. Рэалізацыя была перапісана з выкарыстаннем беззнакавых інструкцый. атрымаўся невялікі, але асноўная праблема складалася ў захаванні хуткасці выканання і выключэнні паніжэння прадукцыйнасці функцый memcpy і memmove, захоўваючы пры гэтым сумяшчальнасць са ўсімі камбінацыямі ўваходных значэнняў.
У пачатку чэрвеня было падрыхтавана два варыянты выпраўлення, якія праходзяць тэставы фрэймворк мэйнтэйнераў Glibc і ўнутраны тэставы набор Аўроры. 3 чэрвеня быў абраны адзін з варыянтаў і у спіс рассылкі Glibc. Праз тыдзень
быў яшчэ адзін аналагічны па падыходзе патч, які выпраўляў праблему ў multiarch-рэалізацыі, якую раней спрабавалі выправіць у Huawei. Месяц заняло тэсціраванне і на ўвазе важнасці патча.
8 ліпеня выпраўленні у асноўную галінку які рыхтуецца рэлізу glibc 2.32. Рэалізацыя ўключае два патчы - для multiarch-рэалізацыі memcpy для ARMv7, а для агульнай асэмблернай рэалізацыі memcpy() і memmove() для ARM.
Праблема закранае мільёны ARMv7-прылад з Linux і без адпаведнага абнаўлення ўладальнікі рызыкуюць, падлучаючы іх да сеткі (атакаваны могуць быць даступныя па сетцы сэрвісы і прыкладанні, якія прымаюць уваходныя дадзеныя без абмежавання памеру). Напрыклад, у эксплоіце, падрыхтаваным якія выявілі ўразлівасць даследнікамі, паказана як здзейсніць напад на ўбудаваны ў аўтамабільную інфармацыйную сістэму http-сервер праз перадачу GET-запыту вельмі вялікага памеру і атрымаць root-доступ да сістэмы.
Крыніца: opennet.ru