noyau: désactivation de / dev / kmem et / dev / mem

Je comprends cela /dev/kmemet je /dev/memdonne accès à la mémoire (c.-à-d. La RAM brute) du système. Je suis également conscient que cela /dev/kmempeut être complètement désactivé dans le noyau et que l'accès peut être restreint /dev/mem.

Il me semble, avoir un accès brut à la mémoire peut être utile pour les développeurs et les pirates, mais pourquoi devrais-je avoir besoin d'accéder à la mémoire /dev/mem. AFAIK il ne peut pas être désactivé dans le noyau (contrairement à /dev/kmem). Avoir accès à une mémoire brute qui peut être potentiellement exploitée / abusée me semble être un problème.

Y a-t-il une utilité pratique pour cela? Y a-t-il des programmes utilisateur qui nécessitent qu'il fonctionne correctement?

Il y a un jeu de diapositives de Scale 7x 2009 intitulé: Undermining the Linux Kernel: Malicious Code Injection via / dev / mem qui contenait ces 2 puces.

Qui en a besoin?

• Serveur X (mémoire vidéo et registres de contrôle)
• DOSEmu

D'après tout ce que j'ai trouvé à partir des recherches jusqu'à présent, il semblerait que ces 2 balles soient les pionniers pour des utilisations légitimes.

Références

• Anthony Lineberry sur / dev / mem Rootkits - LJ 8/2009 par Mick Bauer
• Qui a besoin de / dev / kmem?

Il convient de noter que même si vous avez désactivé /dev/memet /dev/kmemque la mémoire peut encore être vidée; jetez un oeil à man procrévéler /proc/kcore; c'est la mémoire physique du système. Une très bonne boîte à outils forensics rekall a un outil qui fait déjà cela ; il vide la mémoire (et les /bootfichiers) afin qu'ils puissent être analysés.

En fait, Ubuntu désactive par défaut/dev/kmem :

Il n'y a aucune utilisation moderne de /dev/kmemplus que les attaquants qui l'utilisent pour charger les rootkits du noyau. CONFIG_DEVKMEMest réglé sur "n". Bien que le /dev/kmemnœud de périphérique existe toujours dans Ubuntu 8.04 LTS à Ubuntu 9.04, il n'est en fait attaché à rien dans le noyau.

Ubuntu ne se désactive pas /dev/memcar il est nécessaire aux applications .

Certaines applications (Xorg) nécessitent un accès direct à la mémoire physique depuis l'espace utilisateur. Le fichier spécial /dev/memexiste pour fournir cet accès. Dans le passé, il était possible d'afficher et de modifier la mémoire du noyau à partir de ce fichier si un attaquant avait un accès root. L' CONFIG_STRICT_DEVMEMoption du noyau a été introduite pour bloquer l'accès à la mémoire hors périphérique (initialement nommé CONFIG_NONPROMISC_DEVMEM).

Comment désactiver /proc/kcore?

Ne pas activer CONFIG_PROC_KCORElors de la construction du noyau.

Comment désactivez-vous /dev/mem?

Eh bien, regarder plus man memloin nous donne quelques détails sur la façon dont il a été créé:

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

Vous devriez pouvoir juste rm -rf /dev/mem; vous pouvez désactiver pendant la phase de construction du noyau en ne l'activant pas CONFIG_STRICT_DEVMEM.

Comment désactiver /dev/kmem?

Assurez-vous que ce CONFIG_DEVKMEMn'est pas activé lors de la construction du noyau.

Comment empêcher les attaques de démarrage à froid?

Et si je pouvais désactiver /proc/kcore, /dev/mem, /dev/kmempuis utilisé une partition de swap crypté ou n'a pas utilisé du tout échange? Eh bien, votre mémoire pourrait être gelée et accessible de cette façon. Comment empêchez-vous cette attaque? Vous cryptez votre RAM; comment cryptez-vous votre RAM? Tu ne peux pas. Voir TRESOR pour plus de détails .

Comme vous le savez, /dev/memdonne accès à la mémoire physique d'un système en cours d'exécution. /dev/kmemdonne accès à la mémoire virtuelle du noyau. Ces deux périphériques de caractères peuvent être désactivés de manière persistante via les options de configuration du noyau (le code est la source d'information la plus fiable, il est donc utilisé comme référence). La désactivation des deux premières options ci-dessous désactivera les appareils correspondants.

• CONFIG_DEVKMEM: détermine si /dev/kmemest créé au démarrage
• CONFIG_DEVMEM: détermine si /dev/memest créé au démarrage
• CONFIG_STRICT_DEVMEM: s'il /dev/memexiste, détermine si l'accès à celui-ci est restreint

Selon votre distribution, votre configuration actuelle du noyau peut être vue en utilisant quelque chose comme zless /proc/config.gzou less /boot/config-$(uname -r).

Je pense que l'intention initiale de /dev/memétait de soutenir l'interaction avec les périphériques mappés en mémoire . Les implications de sécurité négatives évidentes de la disponibilité de ces périphériques virtuels (par exemple, un attaquant pouvant patcher à la volée la mémoire d'un autre processus ou même le noyau) est connue depuis au moins une décennie. Restreindre l'accès à /dev/mema été pris en charge dans le noyau de la ligne principale depuis le début de 2008 , et /dev/kmemest également facultatif depuis cette date également.

Il y a une décennie, il semble que cela Xdépendait /dev/mem, je ne pense pas que ce soit toujours vrai. Pour tester les affirmations sur la Xnécessité, /dev/memj'ai supprimé le périphérique virtuel de mon ordinateur portable hier et il fonctionne parfaitement depuis. En 2017, il ne semble pas y avoir d'utilisation pratique de ces appareils en dehors de la recherche et du développement.

Du point de vue de la sécurité, il est judicieux de supprimer ces appareils. Il convient de noter qu'un attaquant distant , avec des privilèges élevés, peut lire la mémoire en dehors de son espace d'adressage. La mémoire d'autres applications de l'espace utilisateur est accessible à l'aide de /proc/<pid>/mem. La mémoire du noyau est accessible à l'aide de /proc/kcore.

Je n'ai pas inclus /dev/memsur mon système depuis le début. J'utilise Gentoo Linux, donc cela peut ne pas être surprenant, car avec cette distribution Linux, vous construisez pratiquement tous les packages vous-même, y compris le noyau Linux.

Je n'ai jamais remarqué de problèmes en raison de l'absence de /dev/mem, même lorsque j'utilise X.org X11. Aujourd'hui encore, j'ai remarqué qu'une émergence du package x11-drivers/xf86-video-vesaimprime un message indiquant qu'il nécessite /dev/mem, comme ceci:

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

Étant donné que je n'ai pas installé le pilote VESA pour le XServer intentionnellement, ou même si ce n'est que comme solution de repli, je n'ai jamais eu à l'utiliser et je ne l'ai donc pas remarqué - jusqu'à présent.

Mais cela prouve le point que a) X11 n'a plus besoin /dev/mem, et b) que certains pilotes vidéo X11 peuvent toujours le faire de toute façon.

Les pilotes vidéo plus récents pour un matériel spécifique fonctionneront très probablement sans lui. Tout comme le X.org-X11 moderne (sur Gentoo, x11-base/xorg-server) n'a même plus besoin d'être suid root , voilà à quoi ressemble le progrès ...