Kriitiline haavatavus Glibci ARMv7 memcpy funktsiooni rakendamisel

Cisco turvateadlased katmata üksikasjad haavatavused (CVE-2020-6096) Glibci pakutava funktsiooni memcpy() rakendamisel 32-bitise ARMv7 platvormi jaoks. Probleemi põhjustab kopeeritava ala suuruse määrava parameetri negatiivsete väärtuste vale käsitsemine, mis on tingitud koostu optimeerimise kasutamisest, mis manipuleerib allkirjastatud 32-bitiste täisarvudega. Memcpy() kutsumine negatiivse suurusega ARMv7 süsteemides põhjustab väärtuste vale võrdlemise ja kirjutab väljaspool määratud puhvri piire.

Haavatavust saab ära kasutada koodi käivitamiseks olukorras, kus ründaja saab korraldada muutuja negatiivse väärtuse moodustamise, mille kaudu kopeeritud andmete suurus edastatakse (näiteks muutub see negatiivseks, kui edastada rohkem kui 2 GB andmeid, kuid rünnaku ajal puhvri piiridest ületamiseks peate üle kandma vähemalt 4 GB). Funktsiooni memcpy () kasutatakse laialdaselt rakendustes ja ARMv7 protsessorid on levinud autosüsteemides, mobiil-, tööstus-, tarbija-, side- ja manustatud seadmetes, mis võivad olla rünnakute all Bluetoothi, HD-raadio/DAB-i, USB-, CAN-siini, Wi-Fi Fi ja muud välised andmeallikad (nt rünnata saab võrgu kaudu juurdepääsetavaid teenuseid ja rakendusi, mis aktsepteerivad sisendandmeid ilma suurusepiiranguteta).

Näitena võib tuua toimiva ärakasutamise, et rünnata autode infosüsteemidesse sisseehitatud HTTP-serverit, millele pääseb juurde auto Wi-Fi võrgu kaudu. Väline ründaja võib selle serveri memcpy haavatavust ära kasutada, saates väga suure GET-päringu ja saada süsteemile juurjuurdepääsu.

Kriitiline haavatavus Glibci ARMv7 memcpy funktsiooni rakendamisel

32-bitistes x86 süsteemides seda probleemi ei ilmne, kuna selle arhitektuuri memcpy juurutus tõlgendab suurusmuutujat õigesti kui märgita täisarvu tüübi suurus_t (koostekeeles rakendamine ARMv7 puhul käsitletakse seda märgiga täisarvuna suuruse_t asemel). Parandus on praegu saadaval kujul plaaster, mis lisatakse August Glibc 2.32 värskendusse.
Parandus taandub allkirjastatud operandidel (bge ja blt) töötavate montaažijuhiste kasutamise asendamisele signeerimata vastetega (blo ja bhs).

Probleem ei ole veel lahendatud Debian 9 ja 10 (pole nähtav Debian 8-s), Fedora, Ubuntu, OpenEmbedded, Tizen (kasutab glibc). RHEL и SUSE Seda probleemi see ei mõjuta, kuna need ei toeta 32-bitiseid ARMv7 süsteeme. Haavatavus ei mõjuta Androidi, kuna see kasutab oma libc (Bionic) teostust. IN OpenWRT Vaikimisi kasutab enamik ehitusi Musli, kuid hoidlas on saadaval ka glibc.

Allikas: opennet.ru

Lisa kommentaar