Sikkerhedsforskere fra Cisco detaljer () i implementeringen af memcpy()-funktionen, der tilbydes i Glibc for 32-bit ARMv7-platforme. Problemet skyldes forkert håndtering af negative værdier for parameteren, der angiver størrelsen af det kopierede område, på grund af brugen af assembleroptimeringer, der manipulerer med 32-bit signed heltal. Et kald til memcpy() på ARMv7-systemer med negativ størrelse fører til forkert sammenligning af værdier og skrivning uden for grænserne af den angivne buffer.
Sårbarheden kan udnyttes til at udføre kode i en situation, hvor en angriber kan fremkalde et negativt værdig for variablen, der angiver størrelsen af de kopierede data (for eksempel vil en negativ værdi blive skabt ved at overføre mere end 2 GB data, men i angrebsprocessen skal der overføres mindst 4 GB for at overskride buffergrænserne). memcpy()-funktionen anvendes aktivt i applikationer, og ARMv7-processorer er udbredt i bilsystemer, mobile, industrielle, forbruger-, kommunikations- og indlejrede enheder, som potentielt kan blive mål for angreb ved brug af Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi og andre eksterne datakilder (for eksempel kan netværksbaserede tjenester og applikationer, der modtager inputdata uden størrelsesbegrænsning, blive angrebet).
Som eksempel gives oprettelsen af et funktionelt exploit til angreb på den indbyggede http-server i bilens infotainmentsystem, som er tilgængelig via bilens Wi-Fi-netværk. En uautoriseret angriber kan udnytte sårbarheden i memcpy i denne server ved at sende en meget stor GET-anmodning og få root-adgang til systemet.
På 32-bit x86-systemer optræder problemet ikke, da implementeringen af memcpy for denne arkitektur korrekt fortolker størrelsesvariablen som en unsigned heltalværdi af typen size_t (i den assembler-kodede version, for ARMv7 behandles den i stedet som signed integer). Fixet er endnu tilgængeligt som , som vil blive en del af opdateringen af Glibc 2.32 i august.
Retten består i at erstatte brugen af assemblerinstruktioner, der arbejder med tegnoperander (bge og blt), med ubegribelige ækvivalenter (blo og bhs).
Problemet er endnu ikke løst i (det optræder ikke i Debian 8), , , OpenEmbedded, Tizen (det bruger glibc). og problemet berører ikke, da de ikke understøtter 32-bit ARMv7 systemer. Android er ikke sårbar, da det bruger sin egen implementering af libc (Bionic). I bruger de fleste builds som standard Musl, men der findes også glibc i repository.
Kilde: opennet.ru
