kernel: disabilitando / dev / kmem e / dev / mem

Lo capisco /dev/kmeme /dev/memfornisco l'accesso alla memoria (ovvero RAM grezza) del sistema. Sono anche consapevole che /dev/kmempuò essere completamente disabilitato nel kernel e che l'accesso può essere limitato/dev/mem .

Mi sembra che avere un accesso non elaborato alla memoria possa essere utile per sviluppatori e hacker, ma perché dovrei avere bisogno di accedere alla memoria /dev/mem. AFAIK non può essere disabilitato nel kernel (a differenza /dev/kmem). Avere accesso alla memoria grezza che può essere potenzialmente abusata / sfruttata mi sembra solo chiedere problemi.

C'è qualche uso pratico per questo? Alcuni programmi utente richiedono che funzioni correttamente?

C'è un deck slide di Scale 7x 2009 intitolato: Undermining the Linux Kernel: Malicious Code Injection via / dev / mem che conteneva questi 2 proiettili.

Chi ha bisogno di questo?

• X Server (memoria video e registri di controllo)
• dOSEMU

Da tutto quello che ho trovato dalla ricerca fino ad ora sembrerebbe che questi 2 proiettili siano i migliori per usi legittimi.

Riferimenti

• Anthony Lineberry su / dev / mem Rootkits - LJ 8/2009 di Mick Bauer
• Chi ha bisogno di / dev / kmem?

Vale la pena notare che anche se disabilitato /dev/meme /dev/kmemquella memoria può ancora essere scaricata; dai un'occhiata a man procrivelare /proc/kcore; è la memoria fisica dei sistemi. Un rekall di toolkit forensi davvero buono ha già uno strumento che lo fa ; scarica la memoria (e i /bootfile) in modo che possano essere analizzati.

È un dato di fatto, Ubuntu di default disabilita/dev/kmem :

Non vi è alcun uso moderno di /dev/kmemaltri oltre agli attaccanti che lo usano per caricare i rootkit del kernel. CONFIG_DEVKMEMè impostato su "n". Sebbene il /dev/kmemnodo del dispositivo esista ancora in Ubuntu 8.04 LTS tramite Ubuntu 9.04, in realtà non è collegato a nulla nel kernel.

Ubuntu non si disattiva /dev/memperché è necessario per le applicazioni .

Alcune applicazioni (Xorg) richiedono l'accesso diretto alla memoria fisica dallo spazio utente. Il file speciale /dev/memesiste per fornire questo accesso. In passato, era possibile visualizzare e modificare la memoria del kernel da questo file se un utente malintenzionato avesse accesso come root. L' CONFIG_STRICT_DEVMEMopzione del kernel è stata introdotta per bloccare l'accesso alla memoria non del dispositivo (originariamente chiamato CONFIG_NONPROMISC_DEVMEM).

Come disabilitare /proc/kcore?

Non abilitare CONFIG_PROC_KCOREdurante la compilazione del kernel.

Come si disabilita /dev/mem?

Bene, guardando oltre man memci fornisce alcuni dettagli su come è stato creato:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

Dovresti essere in grado di solo rm -rf /dev/mem; è possibile disabilitare durante la fase di compilazione del kernel non abilitando CONFIG_STRICT_DEVMEM.

Come disabilitare /dev/kmem?

Assicurarsi che CONFIG_DEVKMEMnon sia abilitato al momento della compilazione del kernel.

Come prevenire gli attacchi di avvio a freddo?

Che cosa succede se ero in grado di disabilitare /proc/kcore, /dev/mem, /dev/kmeme poi utilizzato una partizione di swap crittografato o non ha utilizzato di swap a tutti? Bene, la tua memoria potrebbe essere congelata e acceduta in quel modo. Come si impedisce questo attacco? Crittografi la tua RAM; come si crittografa la RAM? Non puoi. Vedi TRESOR per i dettagli .

Come sapete, /dev/memfornisce l'accesso alla memoria fisica di un sistema in esecuzione. /dev/kmemfornisce l'accesso alla memoria virtuale del kernel. Entrambi questi dispositivi a caratteri possono essere permanentemente disabilitati attraverso le opzioni di configurazione del kernel (il codice è la fonte di informazione più autorevole, quindi viene usato come riferimento). Disattivando le prime due opzioni di seguito si disabiliteranno i dispositivi corrispondenti.

• CONFIG_DEVKMEM: determina se /dev/kmemviene creato all'avvio
• CONFIG_DEVMEM: determina se /dev/memviene creato all'avvio
• CONFIG_STRICT_DEVMEM: se /dev/memesiste, determina se l'accesso ad esso è limitato

A seconda della tua distribuzione, la tua attuale configurazione del kernel può essere vista usando qualcosa come zless /proc/config.gzo less /boot/config-$(uname -r).

Penso che l'intenzione iniziale /dev/memfosse quella di supportare l'interazione con le periferiche mappate in memoria . Le ovvie implicazioni di sicurezza negative della disponibilità di questi dispositivi virtuali (ad es. Un attaccante in grado di rattoppare al volo la memoria di un altro processo o persino del kernel) sono noti da almeno un decennio. Limitare l'accesso a /dev/memè stato sostenuto nel kernel mainline dall'inizio del 2008 , /dev/kmemè stato anche facoltativa dal intorno allora troppo.

Un decennio fa sembra Xdipendere da ciò /dev/mem, non credo sia ancora vero. Per testare le affermazioni sulla Xnecessità /dev/memho cancellato ieri il dispositivo virtuale dal mio laptop e da allora ha funzionato in modo perfetto. Nel 2017 non sembra esserci alcun uso pratico di questi dispositivi al di fuori della ricerca e dello sviluppo.

Dal punto di vista della sicurezza, è consigliabile rimuovere questi dispositivi. Vale comunque la pena notare che un utente malintenzionato remoto , con privilegi elevati, può leggere la memoria al di fuori del suo spazio di indirizzi. È possibile accedere alla memoria di altre applicazioni dello spazio utente tramite /proc/<pid>/mem. È possibile accedere alla memoria del kernel utilizzando /proc/kcore.

Non ho incluso /dev/memnel mio sistema dall'inizio. Uso Gentoo Linux, quindi questo potrebbe non sorprendere, dal momento che con questa distribuzione Linux praticamente costruisci tu stesso ogni pacchetto, incluso il kernel Linux.

Non ho mai notato alcun problema a causa della mancanza di /dev/mem, anche quando si utilizza X.org X11. Proprio oggi ho notato che un emergere del pacchetto x11-drivers/xf86-video-vesastampa un messaggio che afferma che richiede /dev/mem, in questo modo:

* This driver requires /dev/mem support in your kernel
*   Device Drivers --->
*     Character devices  --->
*       [*] /dev/mem virtual device support

Dal momento che non ho installato il driver VESA per XServer intenzionalmente, o anche solo come fallback, non ho mai dovuto usare e quindi non me ne sono accorto - fino ad ora.

Ma ciò dimostra che a) X11 non è /dev/mempiù necessario eb) che alcuni driver video X11 potrebbero comunque fare comunque.

I driver video più recenti per hardware specifico funzioneranno molto probabilmente senza di essa. Proprio come il moderno X.org-X11 (su Gentoo, x11-base/xorg-server) non deve nemmeno più essere utilizzato come root , ecco come appaiono i progressi ...