Utvecklare av AuroraOS mobila operativsystem (en gaffel med operativsystemet Sailfish, utvecklat av Open Mobile Platform-företaget) delade en fix för en sårbarhet som de upptäckte i memcpy. Eliminering av kritisk sårbarhet (CVE-2020-6096) i Glibc, som bara manifesterar sig på ARMv7-plattformen.
Information om sårbarheten avslöjades i maj, men fram till de senaste dagarna var korrigeringarna inte tillgängliga, trots att sårbarheten tilldelades en hög risknivå och det finns en fungerande prototyp av exploateringen som gör det möjligt att organisera körningen av koden.
Utnyttjandet förberett fungerar under bearbetning i memcpy () och memmove () funktioner för vissa formaterade data.
Vikten av Glibc är att detta bibliotek definierar systemanrop och andra grundläggande funktioner förutom att det används av nästan alla program.
Om problemet
Sårbarheten manifesterad vid implementeringen av memcpy () och memmove () på monteringsspråk för ARMv7 och det orsakades av felaktig bearbetning av negativa värden för parametern som bestämmer storleken på området.
Problem med patchutveckling startade när SUSE och Red Hat meddelade att deras plattformar inte påverkades på grund av problemet, eftersom de inte kompilerade för 7-bitars ARMv32-system och inte deltog i att skapa korrigeringsfilen.
Utvecklarna av många inbäddade distributioner litade tydligen på Glibc-teamet och deltog inte heller aktivt i förberedelsen av korrigeringsfilen.
lösningar
Huawei erbjöd ett alternativ för en lapp för att blockera problemet nästan omedelbart, som försökte ersätta monteringsinstruktioner som fungerar på signerade operander (bge och blt) med osignerade analoger (blo och bhs).
Glibc-underhållare utvecklade en testsvit för att testa olika förhållanden för förekomst av ett fel efter vilket visade sig att Huaweis patch inte passar och det behandlar inte alla möjliga kombinationer av indata.
Med tanke på att AuroraOS har en 32-bitars byggnad för ARM, Dess utvecklare bestämde sig för att stänga sårbarheten på egen hand och föreslå en lösning för samhället.
Svårigheten var att det var nödvändigt att skriva en effektiv implementering sammansättning av funktionen och överväga flera alternativ för inmatningsargumenten.
Implementeringen har skrivits om med hjälp av osignerade instruktioner. Plåstret visade sig vara litet, men huvudproblemet var att upprätthålla exekveringshastighet och ta bort prestandadegradering från memcpy- och memmove-funktionerna, samtidigt som kompatibiliteten med alla kombinationer av ingångsvärden bibehölls.
I början av juni förbereddes två lösningar, passerar Glibcs underhållstestramverk och Auroras interna testsvit. Den 3 juni valdes ett av alternativen och skickades in till Glibc-e-postlistan.
En vecka senare föreslogs ett annat liknande tillvägagångssätt, som löste problemet i multiarkimplementeringen, som Huawei tidigare hade försökt fixa. En månad tog testning och legalisering med tanke på patchens betydelse.
Den 8 juli godkändes korrigeringar i huvudgrenen av den kommande glibc 2.32-utgåvan. Ansökan innehåller två korrigeringsfiler:
- Den första för en minnesetablering Multiarch-applikation för ARMv7
- Det andra för en gemensam assemblerimplementering av memcpy () och memmove () för ARM.
Problemet påverkar miljontals ARMv7 Linux-enheter och utan en korrekt uppdatering riskerar ägare att ansluta dem till nätverket (tjänster och applikationer som finns tillgängliga i nätverket som accepterar input utan storleksbegränsningar kan attackeras).
Till exempel ett förberett utnyttjande av forskare som upptäckte att sårbarheten visar hur man attackerar en http-server integreras i bilinformationssystemet genom att sända en mycket stor GET-begäran och få root-åtkomst till systemet.
Paketlösningar för Debian och Ubuntu har ännu inte släppts y sårbarheten förblir okorrigerad i nästan två månader från offentliggörandet och fem månader från det att Glibc-utvecklarna underrättades.