Udviklerne af Aurora mobile operativsystem (en gaffel af Sailfish OS udviklet af Open Mobile Platform-virksomheden) delte en afslørende historie om at eliminere () i Glibc, som kun vises på ARMv7-platformen. Oplysninger om sårbarheden blev afsløret tilbage i maj, men indtil de seneste dage var rettelser ikke tilgængelige på trods af, at sårbarhederne et højt niveau af fare, og der er en fungerende prototype af en udnyttelse, der giver dig mulighed for at organisere kodeudførelse, når du behandler data formateret på en bestemt måde i funktionerne memcpy() og memmove(). Pakkerettelser til и er endnu ikke blevet frigivet, og sårbarheden forbliver uløst i næsten to måneder fra tidspunktet for offentliggørelse og fem måneder fra det øjeblik, Glibc-udviklerne blev underrettet.
Sårbarheden manifesterede sig i assemblersprogsimplementeringen af memcpy() og memmove() for ARMv7 og var forårsaget af forkert håndtering af negative værdier af parameteren, der bestemmer størrelsen af det kopierede område. Problemer med patch udvikling begyndte, da virksomheder и meddelte, at deres platforme ikke er berørt af problemet, da de ikke bygger til 32-bit ARMv7-systemer og ikke deltog i at lave en rettelse. Udviklerne af mange indlejrede distributioner ser ud til at have stolet på Glibc-teamet og har heller ikke været aktivt involveret i at forberede rettelsen.
valgmulighed For at blokere problemet foreslog Huawei næsten øjeblikkeligt, at det forsøgte at erstatte monteringsinstruktioner, der opererede med signerede operander (bge og blt) med usignerede analoger (blo og bhs). Glibc-vedligeholdere udviklede et sæt test for at kontrollere forskellige fejltilstande, hvorefter det viste sig, at Huawei-patchen ikke var egnet og ikke behandlede alle mulige kombinationer af inputdata.
Da Aurora OS har en 32-bit build til ARM, besluttede dets udviklere at lukke sårbarheden på egen hånd og tilbyde en løsning til fællesskabet. Vanskeligheden var, at det var nødvendigt at skrive en effektiv assemblersprogimplementering af funktionen og tage højde for forskellige muligheder for input-argumenter. Implementeringen er blevet omskrevet ved hjælp af usignerede instruktioner. Det viste sig at være lille, men hovedproblemet var at opretholde udførelseshastigheden og undgå ydeevneforringelse af memcpy- og memmove-funktionerne, samtidig med at kompatibiliteten med alle kombinationer af inputværdier blev bibeholdt.
I begyndelsen af juni blev to versioner af rettelsen udarbejdet, som bestod testrammerne for Glibc-vedligeholderne og den interne testpakke af Aurora. Den 3. juni blev en af mulighederne valgt og til Glibc-mailinglisten. En uge senere
Det var en anden patch lignende tilgang, som korrigerede et problem i multiarch-implementeringen, som Huawei tidligere havde forsøgt at rette. Testning tog en måned og på grund af plasterets betydning.
8. juli rettelser til hovedgrenen af den kommende glibc 2.32-udgivelse. Implementeringen inkluderer to patches - til multiarch-implementering af memcpy til ARMv7, og til general assembly sprogimplementeringen af memcpy() og memmove() for ARM.
Problemet påvirker millioner af ARMv7-enheder, der kører Linux, og uden den passende opdatering er ejerne i fare, når de forbinder dem til netværket (netværkstilgængelige tjenester og applikationer, der accepterer inputdata uden størrelsesbegrænsninger, kan blive angrebet). For eksempel viser udnyttelsen udarbejdet af forskerne, der identificerede sårbarheden, hvordan man angriber en HTTP-server indbygget i et bilinformationssystem ved at sende en meget stor GET-anmodning og få root-adgang til systemet.
Kilde: opennet.ru