Cisco säkerhetsforskare detaljer () i implementeringen av den Glibc-försedda memcpy()-funktionen för 32-bitars ARMv7-plattformen. Problemet orsakas av felaktig hantering av negativa värden för parametern som bestämmer storleken på det kopierade området, på grund av användningen av monteringsoptimeringar som manipulerar signerade 32-bitars heltal. Att anropa memcpy() på ARMv7-system med en negativ storlek resulterar i felaktig jämförelse av värden och skrivningar i ett område utanför gränserna för den angivna bufferten.
Sårbarheten kan utnyttjas för att exekvera kod i en situation där angriparen kan organisera bildningen av ett negativt värde för variabeln genom vilken storleken på kopierad data överförs (till exempel kommer den att bli negativ vid överföring av mer än 2 GB av data, men under attacken måste du överföra minst 4 GB för att överskrida buffertgränserna). Funktionen memcpy() används ofta i applikationer, och ARMv7-processorer är vanliga i bilsystem, mobila, industriella, konsument-, kommunikations- och inbäddade enheter, som potentiellt är utsatta för attacker med Bluetooth, HD Radio/DAB, USB, CAN-buss, Wi-Fi Fi och andra externa datakällor (till exempel tjänster och applikationer tillgängliga över nätverket som accepterar indata utan storleksbegränsningar kan attackeras).
Ett exempel är skapandet av en fungerande exploatering för att attackera en HTTP-server inbyggd i bilinformationssystem, tillgänglig via bilens Wi-Fi-nätverk. En extern angripare kan utnyttja en memcpy-sårbarhet på denna server genom att skicka en mycket stor GET-förfrågan och få root-åtkomst till systemet.
På 32-bitars x86-system uppstår inte problemet, eftersom memcpy-implementeringen för den här arkitekturen korrekt tolkar storleksvariabeln som ett osignerat heltalsvärde av typen size_t (i assemblerspråk) för ARMv7 behandlas det som heltal med tecken istället för size_t). Fixningen är för närvarande tillgänglig som , som kommer att ingå i August Glibc 2.32-uppdateringen.
Fixeringen går ut på att ersätta användningen av monteringsinstruktioner som fungerar på signerade operander (bge och blt) med osignerade motsvarigheter (blo och bhs).
Problemet är ännu inte löst (syns inte i Debian 8), , , OpenEmbedded, Tizen (används av glibc). и Problemet påverkas inte eftersom de inte stöder 32-bitars ARMv7-system. Android påverkas inte av sårbarheten eftersom den använder sin egen libc (Bionic) implementering. I Som standard använder de flesta byggnader Musl, men glibc är också tillgängligt i förvaret.
Källa: opennet.ru