Cisco-beveiligingsonderzoekers gegevens () bij de implementatie van de door Glibc geleverde memcpy()-functie voor het 32-bits ARMv7-platform. Het probleem wordt veroorzaakt door een onjuiste behandeling van negatieve waarden van de parameter die de grootte van het gekopieerde gebied bepaalt, als gevolg van het gebruik van assemblage-optimalisaties die 32-bit gehele getallen met teken manipuleren. Het aanroepen van memcpy() op ARMv7-systemen met een negatieve grootte resulteert in een onjuiste vergelijking van waarden en schrijft in een gebied buiten de grenzen van de opgegeven buffer.
Het beveiligingslek kan worden misbruikt om code uit te voeren in een situatie waarin de aanvaller de vorming van een negatieve waarde van de variabele kan organiseren waarmee de grootte van de gekopieerde gegevens wordt verzonden (deze wordt bijvoorbeeld negatief als er meer dan 2 GB aan gegevens wordt overgedragen). gegevens, maar tijdens de aanval moet u minimaal 4 GB overbrengen om de bufferlimieten te overschrijden. De memcpy()-functie wordt veel gebruikt in toepassingen, en ARMv7-processors komen vaak voor in autosystemen, mobiele, industriële, consumenten-, communicatie- en embedded apparaten, die potentieel onderhevig zijn aan aanvallen met behulp van Bluetooth, HD Radio/DAB, USB, CAN-bus, Wi-Fi Fi en andere externe gegevensbronnen (bijvoorbeeld services en applicaties die toegankelijk zijn via het netwerk en die invoergegevens accepteren zonder beperkingen op de grootte kunnen worden aangevallen).
Een voorbeeld is de creatie van een werkende exploit om een HTTP-server aan te vallen die is ingebouwd in auto-informatiesystemen en toegankelijk is via het auto-Wi-Fi-netwerk. Een aanvaller van buitenaf zou een memcpy-kwetsbaarheid op deze server kunnen misbruiken door een zeer groot GET-verzoek te verzenden en root-toegang tot het systeem te verkrijgen.
Op 32-bits x86-systemen doet het probleem zich niet voor, omdat de memcpy-implementatie voor deze architectuur de variabele size correct interpreteert als een geheel getal zonder teken van het type size_t (in assembleertaal voor ARMv7 wordt het behandeld als een geheel getal met teken in plaats van size_t). De oplossing is momenteel beschikbaar als , die zal worden opgenomen in de Glibc 2.32-update van augustus.
De oplossing komt neer op het vervangen van het gebruik van assemblage-instructies die werken op ondertekende operanden (bge en blt) door niet-ondertekende tegenhangers (blo en bhs).
Het probleem is nog niet opgelost (niet zichtbaar in Debian 8), , , OpenEmbedded, Tizen (gebruikt door glibc). и Het probleem wordt niet beïnvloed omdat ze geen 32-bits ARMv7-systemen ondersteunen. Android heeft geen last van het beveiligingslek, omdat het gebruik maakt van zijn eigen libc (Bionic)-implementatie. IN Standaard gebruiken de meeste builds Musl, maar glibc is ook beschikbaar in de repository.
Bron: opennet.ru