Problemi di sicurezza nelle patch proposte da un dipendente Huawei per proteggere il kernel Linux

Sviluppatori del progetto Grsecurity retribuzione attenzione alla presenza di una vulnerabilità banalmente sfruttabile nel set di patch HKSP (Huawei Kernel Self Protection), pochi giorni fa proposto per migliorare la sicurezza del kernel Linux. La situazione ricorda caso con Samsung, in cui il tentativo di migliorare la sicurezza del sistema ha portato all'emergere di una nuova vulnerabilità e ha reso più semplice la compromissione dei dispositivi.

Le patch HKSP sono state pubblicate da un dipendente Huawei, includono una menzione di Huawei nel profilo GitHub e utilizzano la parola Huawei nel nome del progetto (HKSP - Huawei Kernel Self Protection). Allo stesso tempo, i rappresentanti di Huawei hanno negato il collegamento del progetto HKSP con l’azienda e hanno affermato che il codice è stato sviluppato su iniziativa personale del dipendente, non è un progetto ufficiale Huawei e non è utilizzato nei prodotti dell’azienda. SU Pagina GitHub HKSP con effetto retroattivo dopo la scoperta anche le vulnerabilità è stato aggiunto Tieni presente che il progetto viene sviluppato nel mio tempo libero per scopi di ricerca.

HKSP include modifiche come la randomizzazione degli offset nella struttura cred, la protezione contro gli attacchi allo spazio dei nomi dell'identificatore dell'utente (spazio dei nomi pid), la separazione dello stack dei processi dall'area mmap, il rilevamento di doppie chiamate alla funzione kfree, il blocco delle perdite attraverso lo pseudo -FS /proc (/proc/ {modules, keys, key-users}, /proc/sys/kernel/* e /proc/sys/vm/mmap_min_addr, /proc/kallsyms), migliorata randomizzazione degli indirizzi dello spazio utente, Ptrace aggiuntivo protezione, protezione smap e smep avanzata, possibilità di vietare l'invio di dati tramite socket raw, bloccando indirizzi errati nei socket UDP e verificando l'integrità dei processi in esecuzione. Include anche il modulo del kernel Ksguard, che ha lo scopo di rilevare i tentativi di introdurre i tipici rootkit.

patch causato Greg Kroah-Hartman, responsabile del mantenimento del ramo stabile del kernel Linux, si è mostrato interessato e ha chiesto all'autore di suddividere la patch monolitica in parti per semplificare la revisione e la promozione al kernel principale. Kees Cook, capo progetto su promozione tecnologia di protezione attiva anche nel kernel Linux positivamente ha risposto alle patch e, tra i problemi, ha attirato l'attenzione sul legame con l'architettura x86 e sulla natura di notifica di molte modalità, che registrano solo le informazioni sul problema, ma non tentano di bloccarlo.

Uno studio della patch condotto dagli sviluppatori di Grsecurity ha rivelato molti errori e punti deboli nel codice e ha anche mostrato l'assenza di un modello di minaccia che consentisse loro di valutare adeguatamente le capacità del progetto. Per dimostrare chiaramente che il codice è stato scritto senza utilizzare metodi di programmazione sicuri, viene fornito un esempio di una banale vulnerabilità nel gestore.
file /proc/ksguard/state, che viene creato con i diritti 0777, il che implica che tutti hanno accesso in scrittura. La funzione ksg_state_write, utilizzata per analizzare i comandi scritti in /proc/ksguard/state, crea un buffer tmp[32] nel quale vengono scritti i dati in base alla dimensione dell'operando passato, senza tenere conto della dimensione del buffer di destinazione e senza controllando il parametro con la dimensione della stringa. Quelli. Per sovrascrivere parte dello stack del kernel, un utente malintenzionato deve semplicemente scrivere una riga appositamente formattata in /proc/ksguard/state.

static ssize_t ksg_state_write(struct file *file, const char __user *buf,
size_t lente, loff_t *offset)
{
valore u64;
carattere tmp[32];
dimensione_t n = 0;

if (copia_da_utente(tmp, buf, len))
return -1;

valore = simple_strtoul(tmp, '\0', 10);
...

Sfrutta il prototipo:

char buf[4096] = { };
int fd = open(“/proc/ksguard/state”, O_WRONLY);
se (fd >= 0) {
write(fd, buf, sizeof(buf));
chiudi(fd);
}

Fonte: opennet.ru

Aggiungi un commento