I ricercatori della 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 determina 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 e scritture al di fuori dei limiti del buffer specificato.
La vulnerabilità può essere sfruttata per eseguire codice in situazioni in cui l'attaccante riesce a generare un valore negativo per la variabile attraverso cui viene passato il dimensionamento dei dati copiati (ad esempio, un valore negativo si verifica quando vengono trasferiti più di 2 GB di dati, ma per superare il limite del buffer è necessario trasferire almeno 4 GB). La funzione memcpy() è ampiamente utilizzata nelle applicazioni, e i processori ARMv7 sono comuni nei sistemic automobilistici, mobili, industriali, di consumo, di comunicazione e negli apparecchi integrati, che possono diventare obiettivi di attacchi tramite Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi e altre fonti di dati esterne (ad esempio, possono essere attaccati servizi e applicazioni disponibili in rete che accettano input senza limitazioni sulle dimensioni).
Come esempio, viene presentata la creazione di un exploit funzionante per attaccare il server http integrato nei sistemi informatici delle automobili, accessibile tramite la rete Wi-Fi dell'auto. Un attaccante esterno può sfruttare una vulnerabilità in memcpy in questo server inviando una richiesta GET di dimensioni molto grandi e ottenere accesso root al sistema.
Sui 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 al posto di size_t è trattata come un intero firmato). La correzione è attualmente disponibile come , che farà parte dell'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 analoghi senza segno (blo e bhs).
Il problema non è ancora stato risolto in (in Debian 8 non si manifesta), , , OpenEmbedded, Tizen (utilizza glibc). e il problema non si applica poiché non supportano i sistemi ARMv7 a 32 bit. Android non è vulnerabile poiché utilizza la propria implementazione di libc (Bionic). In di default, nella maggior parte delle build viene utilizzato Musl, ma è disponibile anche glibc nel repository.
Fonte: opennet.ru
