Utvecklarna av det mobila operativsystemet Aurora (en gaffel av Sailfish OS utvecklat av Open Mobile Platform-företaget) delade en avslöjande historia om att eliminera () i Glibc, som endast visas på ARMv7-plattformen. Information om sårbarheten avslöjades redan i maj, men fram till de senaste dagarna var korrigeringar inte tillgängliga, trots att sårbarheterna en hög risknivå och det finns en fungerande prototyp av en exploatering som låter dig organisera kodexekvering när du bearbetar data formaterad på ett visst sätt i funktionerna memcpy() och memmove(). Paketfixar för и har ännu inte släppts och sårbarheten förblir ofixerad i nästan två månader från det ögonblick då det offentliggjordes och fem månader från det att Glibc-utvecklarna meddelades.
Sårbarheten manifesterade sig i implementeringen av memcpy() och memmove() i assemblerspråk för ARMv7 och orsakades av felaktig bearbetning av negativa värden för parametern som bestämmer storleken på det kopierade området. Problem med patchutveckling började när företag и meddelade att deras plattformar inte påverkas 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 verkar ha förlitat sig på Glibc-teamet och har inte heller varit aktivt involverade i att förbereda korrigeringen.
alternativ För att blockera problemet föreslog Huawei nästan omedelbart att de försökte ersätta monteringsinstruktioner som fungerade med signerade operander (bge och blt) med osignerade analoger (blo och bhs). Glibc-underhållare utvecklade en uppsättning tester för att kontrollera olika feltillstånd, varefter det visade sig att Huawei-patchen inte var lämplig och inte bearbetade alla möjliga kombinationer av indata.
Eftersom Aurora OS har ett 32-bitarsbygge för ARM, beslutade dess utvecklare att stänga sårbarheten på egen hand och erbjuda en lösning till communityn. Svårigheten var att det var nödvändigt att skriva en effektiv assemblerspråkimplementering av funktionen och ta hänsyn till olika alternativ för inmatningsargument. Implementeringen har skrivits om med osignerade instruktioner. Det visade sig vara litet, men huvudproblemet var att bibehålla exekveringshastigheten och undvika prestandaförsämring av memcpy- och memmove-funktionerna, samtidigt som kompatibiliteten med alla kombinationer av ingångsvärden bibehölls.
I början av juni förbereddes två versioner av fixen, som klarade testramverket för Glibc-underhållarna och den interna testsviten av Aurora. Den 3 juni valdes ett av alternativen och till Glibcs e-postlista. En vecka senare
det var en annan patch liknande tillvägagångssätt, som korrigerade ett problem i multiarchimplementeringen, som Huawei tidigare försökt fixa. Testningen tog en månad och på grund av plåstrets betydelse.
8 juli rättelser till huvudgrenen av den kommande glibc 2.32-versionen. Implementeringen inkluderar två patchar − för multiarch-implementeringen av memcpy för ARMv7, och för general assembly-språkimplementeringen av memcpy() och memmove() för ARM.
Problemet påverkar miljontals ARMv7-enheter som kör Linux, och utan lämplig uppdatering är ägare i riskzonen när de ansluter dem till nätverket (nätverkstillgängliga tjänster och applikationer som accepterar indata utan storleksbegränsningar kan attackeras). Exploateringen av forskarna som identifierade sårbarheten visar till exempel hur man attackerar en HTTP-server inbyggd i ett bilinformationssystem genom att skicka en mycket stor GET-förfrågan och få root-åtkomst till systemet.
Källa: opennet.ru