Utviklerne av det mobile operativsystemet Aurora (en gaffel av Sailfish OS utviklet av Open Mobile Platform-selskapet) delte en avslørende historie om å eliminere () i Glibc, som bare vises på ARMv7-plattformen. Informasjon om sårbarheten ble avslørt tilbake i mai, men inntil de siste dagene var ikke rettelser tilgjengelig, til tross for at sårbarhetene et høyt farenivå og det er en fungerende prototype av en utnyttelse som lar deg organisere kodekjøring når du behandler data formatert på en bestemt måte i funksjonene memcpy() og memmove(). Pakkerettinger for и har ennå ikke blitt utgitt, og sårbarheten forblir uløst i nesten to måneder fra øyeblikket av offentliggjøring og fem måneder fra øyeblikket Glibc-utviklerne ble varslet.
Sårbarheten manifesterte seg i implementeringen av memcpy() og memmove() i assemblerspråk for ARMv7 og ble forårsaket av feil behandling av negative verdier av parameteren som bestemmer størrelsen på det kopierte området. Problemer med patchutvikling begynte da selskaper и kunngjorde at plattformene deres ikke er berørt av problemet, siden de ikke bygger for 32-biters ARMv7-systemer, og ikke deltok i å lage en løsning. Utviklerne av mange innebygde distribusjoner ser ut til å ha stolt på Glibc-teamet, og har heller ikke vært aktivt involvert i å utarbeide rettelsen.
alternativ For å blokkere problemet foreslo Huawei nesten umiddelbart at de prøvde å erstatte monteringsinstruksjoner som opererer med signerte operander (bge og blt) med usignerte analoger (blo og bhs). Glibc-vedlikeholdere utviklet et sett med tester for å sjekke ulike feiltilstander, hvoretter det viste seg at Huawei-patchen ikke var egnet og ikke behandlet alle mulige kombinasjoner av inngangsdata.
Siden Aurora OS har en 32-bits build for ARM, bestemte utviklerne seg for å lukke sårbarheten på egenhånd og tilby en løsning til fellesskapet. Vanskeligheten var at det var nødvendig å skrive en effektiv assembly-språkimplementering av funksjonen og ta hensyn til ulike alternativer for input-argumenter. Implementeringen er skrevet om ved å bruke usignerte instruksjoner. Det viste seg å være lite, men hovedproblemet var å opprettholde utførelseshastigheten og unngå ytelsesdegradering av memcpy- og memmove-funksjonene, samtidig som kompatibiliteten ble opprettholdt med alle kombinasjoner av inngangsverdier.
I begynnelsen av juni ble to versjoner av rettelsen utarbeidet, som besto testrammeverket til Glibc-vedlikeholderne og den interne testpakken til Aurora. 3. juni ble et av alternativene valgt og til Glibc-postlisten. En uke senere
det var en annen oppdatering med lignende tilnærming, som korrigerte et problem i multiark-implementeringen, som Huawei tidligere hadde prøvd å fikse. Testingen tok en måned og på grunn av viktigheten av lappen.
8. juli rettelser til hovedgrenen av den kommende glibc 2.32-utgivelsen. Implementeringen inkluderer to patcher − for multiarch-implementering av memcpy for ARMv7, og for generell monteringsspråkimplementering av memcpy() og memmove() for ARM.
Problemet påvirker millioner av ARMv7-enheter som kjører Linux, og uten den riktige oppdateringen er eiere i faresonen når de kobler dem til nettverket (nettverkstilgjengelige tjenester og applikasjoner som aksepterer inndata uten størrelsesbegrensninger kan bli angrepet). For eksempel viser utnyttelsen utarbeidet av forskerne som identifiserte sårbarheten hvordan man angriper en HTTP-server innebygd i et bilinformasjonssystem ved å sende en veldig stor GET-forespørsel og få root-tilgang til systemet.
Kilde: opennet.ru