De ontwikkelaars van het mobiele besturingssysteem Aurora (een afsplitsing van het Sailfish OS ontwikkeld door het bedrijf Open Mobile Platform) deelden een onthullend verhaal over het elimineren () in Glibc, dat alleen op het ARMv7-platform verschijnt. Informatie over de kwetsbaarheid werd al in mei bekendgemaakt, maar tot voor kort waren er geen oplossingen beschikbaar, ondanks het feit dat de kwetsbaarheden er is sprake van een hoog risiconiveau en er is een werkend prototype van een exploit waarmee je de uitvoering van code kunt organiseren bij het verwerken van gegevens die op een bepaalde manier zijn geformatteerd in de functies memcpy() en memmove(). Pakketoplossingen voor и zijn nog niet vrijgegeven en de kwetsbaarheid blijft bijna twee maanden onopgelost vanaf het moment van publieke bekendmaking en vijf maanden vanaf het moment dat de Glibc-ontwikkelaars op de hoogte werden gesteld.
De kwetsbaarheid manifesteerde zich bij de implementatie van memcpy() en memmove() in assembleertaal voor ARMv7 en werd veroorzaakt door een onjuiste verwerking van negatieve waarden van de parameter die de grootte van het gekopieerde gebied bepaalt. Problemen met de ontwikkeling van patches begonnen toen bedrijven и hebben aangekondigd dat hun platforms niet door het probleem worden getroffen, aangezien ze niet bouwen voor 32-bits ARMv7-systemen, en niet hebben deelgenomen aan het maken van een oplossing. De ontwikkelaars van veel ingebedde distributies lijken op het Glibc-team te hebben vertrouwd en zijn ook niet actief betrokken geweest bij het voorbereiden van de oplossing.
optie Om het probleem te blokkeren, stelde Huawei vrijwel onmiddellijk voor dat het zou proberen de montage-instructies die werken met ondertekende operanden (bge en blt) te vervangen door niet-ondertekende analogen (blo en bhs). Glibc-onderhouders ontwikkelden een set tests om verschillende foutcondities te controleren, waarna bleek dat de Huawei-patch niet geschikt was en niet alle mogelijke combinaties van invoergegevens verwerkte.
Omdat Aurora OS een 32-bits build voor ARM heeft, besloten de ontwikkelaars de kwetsbaarheid zelf te dichten en een oplossing aan de gemeenschap aan te bieden. De moeilijkheid was dat het nodig was om een efficiënte assembleertaalimplementatie van de functie te schrijven en rekening te houden met verschillende opties voor invoerargumenten. De implementatie is herschreven met behulp van niet-ondertekende instructies. Het bleek klein, maar het grootste probleem was het handhaven van de uitvoeringssnelheid en het vermijden van prestatieverslechtering van de memcpy- en memmove-functies, terwijl de compatibiliteit met alle combinaties van invoerwaarden behouden bleef.
Begin juni werden twee versies van de oplossing voorbereid, die het testframework van de Glibc-onderhouders en de interne testsuite van Aurora doorstaan. Op 3 juni werd voor één van de opties gekozen en naar de Glibc-mailinglijst. Een week later
был nog een patch met een vergelijkbare aanpak, die een probleem in de multiarch-implementatie corrigeerde, dat Huawei eerder had geprobeerd op te lossen. Het testen duurde een maand en vanwege het belang van de patch.
8 juli correcties naar de hoofdtak van de komende glibc 2.32 release. De implementatie omvat twee patches − voor de multiarch-implementatie van memcpy voor ARMv7, en voor de algemene assembleertaalimplementatie van memcpy() en memmove() voor ARM.
Het probleem treft miljoenen ARMv7-apparaten waarop Linux draait, en zonder de juiste update lopen eigenaren risico als ze deze op het netwerk aansluiten (netwerktoegankelijke services en applicaties die invoergegevens accepteren zonder beperkingen op de grootte kunnen worden aangevallen). De exploit die is voorbereid door de onderzoekers die de kwetsbaarheid hebben geïdentificeerd, laat bijvoorbeeld zien hoe je een HTTP-server kunt aanvallen die is ingebouwd in een auto-informatiesysteem door een zeer groot GET-verzoek te verzenden en root-toegang tot het systeem te krijgen.
Bron: opennet.ru