Gli sviluppatori del sistema operativo mobile Aurora (un fork del sistema operativo Sailfish sviluppato dalla società Open Mobile Platform) hanno condiviso una storia rivelatrice sull'eliminazione () in Glibc, che appare solo sulla piattaforma ARMv7. Le informazioni sulla vulnerabilità erano state divulgate già a maggio, ma fino a pochi giorni fa non erano disponibili correzioni, nonostante il fatto che le vulnerabilità un alto livello di pericolo ed esiste un prototipo funzionante di un exploit che consente di organizzare l'esecuzione del codice durante l'elaborazione di dati formattati in un certo modo nelle funzioni memcpy() e memmove(). Correzioni del pacchetto per и non sono stati ancora rilasciati e la vulnerabilità rimane irrisolta per quasi due mesi dal momento della divulgazione pubblica e cinque mesi dal momento in cui gli sviluppatori di Glibc ne sono stati informati.
La vulnerabilità si è manifestata nell'implementazione di memcpy() e memmove() in linguaggio assembly per ARMv7 ed è stata causata da un'errata elaborazione dei valori negativi del parametro che determina la dimensione dell'area copiata. I problemi con lo sviluppo delle patch sono iniziati quando le aziende и ha annunciato che le proprie piattaforme non sono interessate dal problema, poiché non sono progettate per sistemi ARMv32 a 7 bit e non hanno partecipato alla creazione di una correzione. Gli sviluppatori di molte distribuzioni embedded sembrano aver fatto affidamento sul team di Glibc, e inoltre non sono stati attivamente coinvolti nella preparazione della correzione.
opzione Per bloccare il problema, Huawei ha proposto quasi subito di provare a sostituire le istruzioni di montaggio operanti con operandi con segno (bge e blt) con analoghi senza segno (blo e bhs). I manutentori di Glibc hanno sviluppato una serie di test per verificare varie condizioni di errore, dopo di che si è scoperto che la patch Huawei non era adatta e non elaborava tutte le possibili combinazioni di dati di input.
Poiché Aurora OS ha una build a 32 bit per ARM, i suoi sviluppatori hanno deciso di eliminare la vulnerabilità da soli e offrire una soluzione alla comunità. La difficoltà era che era necessario scrivere un'implementazione efficiente della funzione in linguaggio assembly e tenere conto di varie opzioni per gli argomenti di input. L'implementazione è stata riscritta utilizzando istruzioni senza segno. Si è rivelato piccolo, ma il problema principale era mantenere la velocità di esecuzione ed evitare il degrado delle prestazioni delle funzioni memcpy e memmove, pur mantenendo la compatibilità con tutte le combinazioni di valori di input.
All'inizio di giugno sono state preparate due versioni del fix, superando il framework di test dei manutentori di Glibc e la suite di test interna di Aurora. Il 3 giugno è stata scelta una delle opzioni e alla mailing list di Glibc. Una settimana dopo
E 'stato un'altra patch simile nell'approccio, che ha corretto un problema nell'implementazione multiarch, che Huawei aveva precedentemente provato a risolvere. I test sono durati un mese e a causa dell'importanza della patch.
Correzioni dell'8 luglio al ramo principale della prossima versione di glibc 2.32. L'implementazione include due patch − per l'implementazione multiarch di memcpy per ARMv7 e per l'implementazione generale del linguaggio assembly di memcpy() e memmove() per ARM.
Il problema riguarda milioni di dispositivi ARMv7 che eseguono Linux e, senza l'aggiornamento appropriato, i proprietari corrono rischi quando li collegano alla rete (i servizi accessibili dalla rete e le applicazioni che accettano dati di input senza limiti di dimensione possono essere attaccati). L'exploit preparato dai ricercatori che hanno individuato la vulnerabilità mostra ad esempio come attaccare un server HTTP integrato nel sistema informativo di un'auto inviando una richiesta GET di grandi dimensioni e ottenendo l'accesso root al sistema.
Fonte: opennet.ru