Glibc შეიცავს Aurora OS დეველოპერების მიერ მომზადებულ memcpy დაუცველობის გამოსწორებას

Aurora მობილური ოპერაციული სისტემის დეველოპერებმა (Open Mobile Platform კომპანიის მიერ შემუშავებული Sailfish OS-ის ჩანგალი) გააზიარეს გამოვლენილი ამბავი აღმოფხვრის შესახებ. კრიტიკული დაუცველობა (CVE-2020-6096) Glibc-ში, რომელიც ჩნდება მხოლოდ ARMv7 პლატფორმაზე. ინფორმაცია დაუცველობის შესახებ ჯერ კიდევ მაისში გავრცელდა, მაგრამ ბოლო დღეებამდე, გამოსწორებები არ იყო ხელმისაწვდომი, მიუხედავად იმისა, რომ დაუცველობა დანიშნული საფრთხის მაღალი დონე და არსებობს ექსპლოიტის სამუშაო პროტოტიპი, რომელიც საშუალებას გაძლევთ მოაწყოთ კოდის შესრულება memcpy() და memmove() ფუნქციებში გარკვეული ფორმით ფორმატირებული მონაცემების დამუშავებისას. პაკეტის შესწორებები ამისთვის Debian и Ubuntu ჯერ არ გამოქვეყნებულა და დაუცველობა გამოუსწორებელი რჩება თითქმის ორი თვის განმავლობაში საჯარო გამჟღავნების მომენტიდან და ხუთი თვის განმავლობაში Glibc დეველოპერების შეტყობინებიდან.

დაუცველობა გამოიხატა ARMv7-ისთვის ასამბლეის ენაში memcpy() და memmove() დანერგვით და გამოწვეული იყო პარამეტრის უარყოფითი მნიშვნელობების არასწორი დამუშავებით, რომელიც განსაზღვრავს კოპირებული ტერიტორიის ზომას. პრობლემები პატჩის განვითარებასთან დაკავშირებით დაიწყო, როდესაც კომპანიები სუსე и Red Hat გამოაცხადა, რომ მათ პლატფორმებზე პრობლემა არ არის დაზარალებული, რადგან ისინი არ აშენებენ 32-ბიტიან ARMv7 სისტემებს და არ მონაწილეობენ გამოსწორების შექმნაში. ბევრი ჩაშენებული დისტრიბუციის დეველოპერები, როგორც ჩანს, ეყრდნობოდნენ Glibc გუნდს და ასევე არ იყვნენ აქტიურად ჩართული გამოსწორების მომზადებაში.

ვარიანტი პატჩი პრობლემის დაბლოკვის მიზნით, Huawei-მ თითქმის მაშინვე შესთავაზა, რომ შეეცადა შეცვალოს ხელმოწერილი ოპერანდებით (bge და blt) მოქმედი ასამბლეის ინსტრუქციები ხელმოუწერელი ანალოგებით (blo და bhs). Glibc-ის შემსრულებლებმა შეიმუშავეს ტესტების ნაკრები სხვადასხვა შეცდომის პირობების შესამოწმებლად, რის შემდეგაც აღმოჩნდა, რომ Huawei-ის პატჩი არ იყო შესაფერისი და არ ამუშავებდა შეყვანის მონაცემების ყველა შესაძლო კომბინაციას.

ვინაიდან Aurora OS-ს აქვს 32-ბიტიანი კონსტრუქცია ARM-ისთვის, მისმა დეველოპერებმა გადაწყვიტეს, დამოუკიდებლად დაეხურათ დაუცველობა და შესთავაზონ გამოსავალი საზოგადოებას. სირთულე ის იყო, რომ საჭირო იყო ფუნქციის ეფექტური ასამბლეის ენაზე დაწერა და შეყვანის არგუმენტების სხვადასხვა ვარიანტების გათვალისწინება. განხორციელება გადაწერილია ხელმოუწერელი ინსტრუქციების გამოყენებით. პატჩი აღმოჩნდა პატარა, მაგრამ მთავარი პრობლემა იყო შესრულების სიჩქარის შენარჩუნება და memcpy და memmove ფუნქციების შესრულების დეგრადაციის თავიდან აცილება, შეყვანის მნიშვნელობების ყველა კომბინაციასთან თავსებადობის შენარჩუნებისას.

ივნისის დასაწყისში მომზადდა შესწორების ორი ვერსია, გაიარა Glibc-ის შემსრულებლების სატესტო ჩარჩო და Aurora-ს შიდა სატესტო კომპლექტი. 3 ივნისს ერთ-ერთი ვარიანტი აირჩიეს და გაგზავნილი Glibc საფოსტო სიაში. Ერთი კვირის შემდეგ
იყო შემოთავაზებული კიდევ ერთი მსგავსი მიდგომა, რომელმაც გამოასწორა პრობლემა მრავალარხიანი იმპლემენტაციის დროს, რომლის გამოსწორებასაც Huawei ადრე ცდილობდა. ტესტირებას ერთი თვე დასჭირდა და იურიდიული რეგისტრაცია პაჩის მნიშვნელობიდან გამომდინარე.
8 ივლისის შესწორებები მიიღეს მომავალი glibc 2.32 გამოშვების მთავარ ფილიალში. განხორციელება მოიცავს ორ პაჩს − первый ARMv7-ისთვის memcpy-ის მრავალარხიანი განხორციელებისთვის და მეორე memcpy() და memmove() ARM-ისთვის გენერალური ასამბლეის ენის განხორციელებისთვის.

პრობლემა გავლენას ახდენს მილიონობით ARMv7 მოწყობილობაზე Linux შესაბამისი განახლების გარეშე, მფლობელები რისკავენ მათ ქსელთან დაკავშირების შესაძლებლობას (შესაძლოა, თავდასხმის ობიექტი გახდეს ქსელში ხელმისაწვდომი სერვისები და აპლიკაციები, რომლებიც იღებენ შეყვანის მონაცემებს ზომის შეზღუდვის გარეშე). მაგალითად, დაუცველობის აღმოჩენის მკვლევრების მიერ მომზადებული ექსპლოიტი აჩვენებს, თუ როგორ შეიძლება ავტომობილის საინფორმაციო სისტემაში ჩაშენებულ HTTP სერვერზე თავდასხმა ძალიან დიდი GET მოთხოვნის გაგზავნით და სისტემაზე root წვდომის მოპოვებით.

წყარო: opennet.ru