A biztonsági kutatók a Cisco cégtől a részleteket () a Glibc memcpy() függvényének megvalósításában a 32 bites ARMv7 platformon. A probléma a mérethatározás során a negatív értékek helytelen kezeléséből adódik, amely a 32 bites egész számokkal való manipulációt végző assembler-optimalizálások miatt következik be. A memcpy() hívása ARMv7 rendszereken negatív mérettel helytelen értékek összehasonlításához és a megadott puffer határain kívüli területekre való íráshoz vezet.
A sérülékenység kihasználható kód végrehajtására olyan helyzetekben, amikor a támadó negatív értékű változót tud létrehozni, amely a másolt adatok méretét képviseli (például negatív értéket lehet kapni 2 GB-nál nagyobb adatmennyiség átvitele során, de a puffer túllépéséhez legalább 4 GB-ot kell átadni). A memcpy() függvényt széles körben használják alkalmazásokban, és az ARMv7 processzorok elterjedtek autós rendszerekben, mobil, ipari, fogyasztói, kommunikációs és beágyazott eszközökben, amelyek potenciálisan célpontokká válhatnak Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi és más külső adatforrásokból származó támadásokkal (például támadhatóak az interneten elérhető szolgáltatások és alkalmazások, amelyek korlátozás nélküli bemenetet fogadnak).
Példaként bemutatásra kerül egy működő exploit elkészítése, amely támadást indít az autós információs rendszerekbe beépített http-szerver ellen, amely elérhető az autó Wi-Fi hálózatán. Az idegen támadó kihasználhatja a memcpy sérülékenységét a szerveren keresztül, ha nagyon nagy méretű GET-kérést küld, és root-hozzáférést szerez a rendszerhez.
A 32 bites x86 rendszereken a probléma nem jelentkezik, mivel a memcpy ezen architektúrára vonatkozó megvalósítása helyesen értelmezi a méret változót unsigned integer (size_t) típusúként (a letartott assembler-alapú ARMv7 esetén a size_t helyett signed integer-ként dolgozzák fel). A javítás jelenleg elérhető egy , amely bekerül a májusi Glibc 2.32 frissítésbe.
A javítás az assembler utasítások olyan használatának cseréjét jelenti, amelyek signed operátorokkal dolgoznak (bge és blt), unsigned megfelelőikre (blo és bhs).
A probléma jelenleg még nem került orvoslásra a (Debian 8-ban nem jelentkezik) , , OpenEmbedded, Tizen (glibc-t használ). és a probléma nem érinti, mivel nem támogatják a 32 bites ARMv7 rendszereket. Az Android nem érintett a sebezhetőségben, mert saját libc (Bionic) megvalósítást használ. A alapértelmezés szerint a legtöbb összeállításban Muslt használ, de elérhető glibc is a tárolóban.
Forrás: opennet.ru
