Printk () causa problemi di sicurezza?

2

Mi sto chiedendo se la funzione printk() causi problemi di sicurezza su Linux. Quando un utente malintenzionato ha accesso al livello utente al sistema, gli semplifica la vita se ha accesso ai puntatori del kernel? L'utilizzo di printk() lo supporta in qualsiasi modo durante la ricerca di alcune vulnerabilità di escalation dei privilegi nel sistema?

Può essere facilmente disabilitato impostando CONFIG_PRINTK=n come flag di configurazione del kernel Linux. Dovrebbe essere fatto su un sistema altamente sicuro? Com'è sui sistemi embedded? (So che il sistema sarà molto silenzioso in seguito.) Qualcuno ha qualche raccomandazione o esperienza su questo?

    
posta phips 15.11.2018 - 06:38
fonte

1 risposta

1

I'm asking my self if the function printk() is a security issue on Linux.

Dipende se ci sono o meno chiamate printk() che possono stampare puntatori non pubblicitari. Generalmente, i puntatori verranno disinfettati quando kernel.kptr_restrict non è zero. Questo funziona perché l'identificatore per i puntatori è %pK , che sanifica i puntatori per impostazione predefinita. Tuttavia, sembrano esserci molte situazioni in cui gli errori causano perdite accidentale del puntatore, ad esempio perché alcuni valori vengono calcolati da un puntatore e stampati, o perché un errore di battitura risulta invece in %pk , che non passa attraverso lo stesso processo di sanitizzazione. Questo non è unico per questa funzione e può anche successo nei filesystem virtuali come anche proc e sysfs. Questi simboli non sono rari.

When an attacker has user level access to the system, does it make his life easier if he has access to kernel pointers?

Bene si e no. La cosa peggiore che un utente malintenzionato possa fare * con i puntatori del kernel è scoprire l'offset di base del kernel per interrompere KASLR. Sfortunatamente, KASLR è già abbastanza inutile contro gli attaccanti locali, come è stato mostrato tempo e ora di nuovo (più spesso da Brad Spengler). Può essere sconfitto sia tramite i servizi di infoleaks come sopra menzionato, sia attraverso una serie di attacchi temporali contro la maggior parte delle architetture della CPU.

It can be easily disabled through setting CONFIG_PRINTK as configuration flag of the Linux kernel. Should it be done on a highly secured system?

No. C'è un'opzione migliore. Invece di disabilitare la stampa, è necessario disporre di privilegi elevati per leggere il buffer del registro del kernel. Questo può essere fatto impostando kernel.dmesg_restrict a 1. Questo protegge entrambi dai puntatori che non vengono disinfettati e che perdono nel syslog dall'essere disponibili agli aggressori, oltre a nascondere altre informazioni potenzialmente sensibili che potrebbero essere stampate lì.

* Questo è vero solo per i kernel di riserva. Se compili il tuo kernel, specialmente se usi RANDSTRUCT , la conoscenza dei puntatori diventa molto più preziosa dal momento che può consentire di individuare il offset effettivo delle funzioni sensibili del kernel.

    
risposta data 15.11.2018 - 09:30
fonte

Leggi altre domande sui tag