I ricercatori di sicurezza di Cisco dettagli () nell'implementazione fornita nella funzione memcpy() di Glibc per la piattaforma ARMv7 a 32 bit. Il problema è causato da una gestione errata dei valori negativi del parametro che definisce la dimensione dell'area da copiare, a causa dell'uso di ottimizzazioni in assembly che manipolano interi firmati a 32 bit. La chiamata a memcpy() su sistemi ARMv7 con una dimensione negativa provoca confronti errati dei valori e scritture fuori dai limiti del buffer specificato.
La vulnerabilità può essere sfruttata per eseguire codice in situazioni in cui un attaccante può generare un valore negativo nella variabile che trasmette la dimensione dei dati da copiare (ad esempio, un valore negativo si avrà quando si trasferiscono più di 2 GB di dati, ma durante un attacco per oltrepassare i limiti del buffer è necessario trasmettere almeno 4 GB). La funzione memcpy() è ampiamente utilizzata nelle applicazioni e i processori ARMv7 sono comuni in sistemi automobilistici, dispositivi mobili, industriali, di consumo, comunicazione e incorporati, che possono potenzialmente diventare obiettivi di attacchi tramite Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi e altre fonti di dati esterne (ad esempio, servizi e applicazioni accessibili in rete che accettano input senza limitazioni di dimensione possono essere attaccati).
Un esempio è la creazione di un exploit funzionante per attaccare il server http incorporato nei sistemi informatici automobilistici, accessibile tramite la rete Wi-Fi dell'auto. Un attaccante esterno può sfruttare la vulnerabilità in memcpy su questo server inviando una richiesta GET di dimensioni molto grandi e ottenere accesso root al sistema.
Su sistemi x86 a 32 bit, il problema non si manifesta, poiché l'implementazione di memcpy per questa architettura interpreta correttamente la variabile di dimensione come un valore intero senza segno di tipo size_t (nella scrittura in assembly per ARMv7, invece di size_t viene trattata come un intero firmato). La correzione è attualmente disponibile in forma di , che sarà inclusa nell'aggiornamento di agosto di Glibc 2.32.
La correzione consiste nella sostituzione dell'uso di istruzioni in assembly che operano su operandi firmati (bge e blt) con i loro equivalenti senza segno (blo e bhs).
Il problema non è ancora risolto in (in Debian 8 non si manifesta), , , OpenEmbedded, Tizen (utilizza glibc). e il problema non riguarda, poiché non supportano i sistemi ARMv7 a 32 bit. Android non è vulnerabile, poiché utilizza una propria implementazione della libc (Bionic). In default nella maggior parte delle versioni viene utilizzato Musl, ma nel repository è presente anche glibc.
Fonte: opennet.ru
