Կրիտիկական խոցելիություն ARMv7-ի համար memcpy ֆունկցիայի իրականացման մեջ Glibc-ից

Cisco անվտանգության հետազոտողներ բացված մանրամասները խոցելիություններ (CVE-2020-6096- ը) 32-բիթանոց ARMv7 պլատֆորմի համար Glibc-ով տրամադրված memcpy() ֆունկցիան իրականացնելիս: Խնդիրն առաջանում է պատճենված տարածքի չափը որոշող պարամետրի բացասական արժեքների սխալ մշակման պատճառով՝ պայմանավորված 32-բիթանոց ստորագրված ամբողջ թվերով շահարկող հավաքման օպտիմալացումների կիրառմամբ: Բացասական չափով ARMv7 համակարգերի վրա memcpy() կանչելը հանգեցնում է արժեքների սխալ համեմատության և գրում է նշված բուֆերի սահմաններից դուրս գտնվող տարածքում:

Խոցելիությունը կարող է օգտագործվել կոդը գործարկելու համար այն իրավիճակում, երբ հարձակվողը կարող է կազմակերպել փոփոխականի բացասական արժեքի ձևավորումը, որի միջոցով փոխանցվում է պատճենված տվյալների չափը (օրինակ, այն բացասական կլինի 2 ԳԲ-ից ավելի փոխանցման ժամանակ: տվյալները, սակայն հարձակման ժամանակ բուֆերային սահմաններից դուրս գալու համար անհրաժեշտ է փոխանցել առնվազն 4 ԳԲ): Memcpy() ֆունկցիան լայնորեն օգտագործվում է հավելվածներում, և ARMv7 պրոցեսորները տարածված են ավտոմոբիլային համակարգերում, շարժական, արդյունաբերական, սպառողական, կապի և ներկառուցված սարքերում, որոնք պոտենցիալ ենթարկվում են հարձակումների՝ օգտագործելով Bluetooth, HD Radio/DAB, USB, CAN ավտոբուս, Wi-Fi Fi-ը և տվյալների այլ արտաքին աղբյուրները (օրինակ, ցանցի միջոցով հասանելի ծառայություններն ու հավելվածները, որոնք ընդունում են մուտքային տվյալներ առանց չափի սահմանափակումների, կարող են հարձակման ենթարկվել):

Օրինակ՝ աշխատանքային շահագործման ստեղծումը՝ ավտոմեքենայի տեղեկատվական համակարգերում ներկառուցված HTTP սերվերի վրա հարձակվելու համար, որը հասանելի է ավտոմոբիլային Wi-Fi ցանցի միջոցով: Արտաքին հարձակվողը կարող է օգտագործել memcpy-ի խոցելիությունը այս սերվերում՝ ուղարկելով շատ մեծ GET հարցում և ստանալ արմատային մուտք դեպի համակարգ:

Կրիտիկական խոցելիություն ARMv7-ի համար memcpy ֆունկցիայի իրականացման մեջ Glibc-ից

32-բիթանոց x86 համակարգերում խնդիրը չի երևում, քանի որ memcpy-ի ներդրումն այս ճարտարապետության համար ճիշտ է մեկնաբանում չափի փոփոխականը որպես size_t տեսակի անստորագիր ամբողջ արժեք (ասամբլեային լեզվով): իրականացումը ARMv7-ի համար այն դիտվում է որպես ստորագրված ամբողջ թիվ size_t-ի փոխարեն): Ուղղումը ներկայումս հասանելի է որպես կարկատել, որը կներառվի օգոստոսի Glibc 2.32 թարմացման մեջ։
Ուղղումը հանգում է նրան, որ հավաքման հրահանգների օգտագործումը, որոնք գործում են ստորագրված օպերանդներով (bge և blt) անստորագիր գործընկերներով (blo և bhs) փոխարինելով:

Խնդիրը դեռ չի լուծվել Debian 9 և 10 (տեսանելի չէ Debian 8-ում), Fedora, Ubuntu, OpenEmbedded, Tizen (օգտագործվում է glibc-ի կողմից): RHEL- ը и Suse Խնդիրը չի ազդում, քանի որ դրանք չեն աջակցում 32-բիթանոց ARMv7 համակարգեր: Android-ի վրա խոցելիությունը չի ազդում, քանի որ այն օգտագործում է իր սեփական libc (Bionic) ներդրումը: IN OpenWRT Լռելյայնորեն, կառուցումների մեծ մասը օգտագործում է Musl, բայց glibc-ը հասանելի է նաև պահեստում:

Source: opennet.ru

Добавить комментарий