Utvecklarna av mobiloperativsystemet "Aurora" (en förgrening av Sailfish OS, utvecklat av företaget "Open Mobile Platform") delade en illustrativ berättelse om elimineringen. () i Glibc, som bara finns på ARMv7-plattformen. Information om sårbarheten avslöjades i maj, men fram till nyligen fanns ingen åtgärd tillgänglig, trots att sårbarheterna hög risknivå och det finns en fungerande prototyp av ett exploit som tillåter organisering av exekvering av kod vid bearbetning av data formaterad på ett visst sätt i funktionerna memcpy() och memmove(). Paketfixar för и har ännu inte släppts och sårbarheten har förblivit opatchad i nästan två månader sedan den offentliggjordes och fem månader sedan Glibc-utvecklarna underrättades.
Sårbarheten fanns i assemblerspråksimplementeringen av memcpy() och memmove() för ARMv7 och orsakades av felaktig hantering av negativa värden för parametern som bestämmer storleken på det kopierade området. Problemen med att utveckla patchar började med att företagen и meddelade att deras plattformar inte påverkades av problemet, eftersom de inte bygger för 32-bitars ARMv7-system, och inte deltog i att skapa en fix. Utvecklarna av många inbäddade distributioner förlitade sig tydligen på Glibc-teamet, och deltog inte heller aktivt i att förbereda en fix.
alternativ Huawei föreslog nästan omedelbart en lösning för att blockera problemet, genom att försöka ersätta assemblerinstruktioner som arbetar med signerade operander (bge och blt) med osignerade analoger (blo och bhs). Glibc-ansvariga utvecklade en uppsättning tester för att kontrollera olika feltillstånd, varefter det visade sig att Huaweis patch inte var lämplig och inte bearbetade alla möjliga kombinationer av indata.
Eftersom Aurora OS har en 32-bitarsversion för ARM, beslutade utvecklarna att själva åtgärda sårbarheten och erbjuda en lösning till communityn. Svårigheten var att det var nödvändigt att skriva en effektiv assemblerimplementering av funktionen och ta hänsyn till olika alternativ för inmatningsargument. Implementeringen skrevs om med osignerade instruktioner. visade sig vara liten, men det största problemet var att bibehålla exekveringshastigheten och undvika prestandaförsämring för funktionerna memcpy och memmove, samtidigt som kompatibiliteten med alla kombinationer av indatavärden bibehölls.
I början av juni förbereddes två versioner av fixen, som klarade Glibc-utvecklarnas testramverk och Auroras interna testsvit. Den 3 juni valdes en av versionerna ut och till Glibc-e-postlistan. Om en vecka
det var ytterligare en liknande patch i tillvägagångssättet, som åtgärdade ett problem i multiarch-implementeringen, vilket Huawei tidigare hade försökt åtgärda. Det tog en månad att testa och på grund av plåstrets betydelse.
Korrigeringar den 8 juli in i huvudgrenen i den kommande glibc 2.32-utgåvan. Implementeringen inkluderar två patchar — för multiarch memcpy-implementeringen för ARMv7, och för en general assembly-implementering av memcpy() och memmove() för ARM.
Problemet påverkar miljontals ARMv7-enheter med Linux Utan lämplig uppdatering riskerar ägare att ansluta dem till nätverket (nätverksåtkomliga tjänster och applikationer som accepterar indata utan storleksbegränsningar kan attackeras). Till exempel visar det exploit som utarbetats av forskarna som upptäckte sårbarheten hur man kan attackera HTTP-servern som är inbyggd i fordonets informationssystem genom att skicka en mycket stor GET-begäran och få root-åtkomst till systemet.
Källa: opennet.ru
