Ciscon tietoturvatutkijat детали () toteutettaessa Glibc-toimittamaa memcpy()-funktiota 32-bittiselle ARMv7-alustalle. Ongelma johtuu kopioitavan alueen koon määrittävän parametrin negatiivisten arvojen virheellisestä käsittelystä, joka johtuu etumerkillisiä 32-bittisiä kokonaislukuja käsittelevien kokoonpanooptimointien käytöstä. Memcpy():n kutsuminen ARMv7-järjestelmissä, joiden koko on negatiivinen, johtaa virheelliseen arvojen vertailuun ja kirjoittaa määritellyn puskurin rajojen ulkopuolella olevalle alueelle.
Haavoittuvuutta voidaan hyödyntää koodin suorittamisessa tilanteessa, jossa hyökkääjä voi järjestää negatiivisen arvon muodostuksen muuttujalle, jonka kautta kopioitujen tietojen koko välitetään (esimerkiksi se muuttuu negatiiviseksi siirrettäessä yli 2 Gt tietoja, mutta hyökkäyksen aikana puskurin rajojen ylittämiseksi sinun on siirrettävä vähintään 4 Gt). Memcpy()-toimintoa käytetään laajalti sovelluksissa, ja ARMv7-prosessorit ovat yleisiä autojärjestelmissä, mobiili-, teollisuus-, kuluttaja-, viestintä- ja sulautetuissa laitteissa, jotka ovat mahdollisesti alttiina hyökkäyksille Bluetoothin, HD Radio/DAB:n, USB:n, CAN-väylän, Wi-Fi Fi ja muut ulkoiset tietolähteet (esimerkiksi verkon kautta saatavilla olevat palvelut ja sovellukset, jotka hyväksyvät syötetiedot ilman kokorajoituksia, voidaan hyökätä).
Esimerkki on toimivan hyväksikäytön luominen auton tietojärjestelmiin sisäänrakennetun HTTP-palvelimen hyökkäämiseksi, joka on käytettävissä auton Wi-Fi-verkon kautta. Ulkopuolinen hyökkääjä voi hyödyntää tämän palvelimen memcpy-haavoittuvuutta lähettämällä erittäin suuren GET-pyynnön ja saada pääkäyttäjän oikeudet järjestelmään.
32-bittisissä x86-järjestelmissä ongelmaa ei ilmene, koska tämän arkkitehtuurin memcpy-toteutus tulkitsee kokomuuttujan oikein etumerkittömäksi kokonaislukuarvoksi tyyppiä size_t (kokoonpanokielellä ARMv7:ssä sitä käsitellään etumerkillisenä kokonaislukuna koon_t) sijaan). Korjaus on tällä hetkellä saatavilla nimellä , joka sisällytetään August Glibc 2.32 -päivitykseen.
Korjaus tiivistyy siihen, että allekirjoitetuille operandeille (bge ja blt) toimivien kokoonpanoohjeiden käyttö korvataan allekirjoittamattomilla vastineilla (blo ja bhs).
Ongelmaa ei ole vielä ratkaistu (ei näy Debian 8:ssa), , , OpenEmbedded, Tizen (glibc:n käyttämä). и Tämä ei vaikuta ongelmaan, koska ne eivät tue 32-bittisiä ARMv7-järjestelmiä. Haavoittuvuus ei vaikuta Androidiin, koska se käyttää omaa libc (Bionic) -toteutusta. SISÄÄN Oletusarvoisesti useimmat koontiversiot käyttävät Muslia, mutta glibc on myös saatavilla arkistossa.
Lähde: opennet.ru