kernel: désactiver / dev / kmem et / dev / mem

Je comprends que /dev/kmem et /dev/mem donnent access à la memory (c'est-à-dire la RAM brute) du système. Je suis également conscient que /dev/kmem peut être complètement désactivé dans le kernel et que l'access peut être restreint pour /dev/mem .

Il me semble, avoir un access brut à la memory peut être utile pour les développeurs et les pirates, mais pourquoi devrais-je avoir access à la memory via /dev/mem . AFAIK, il ne peut pas être désactivé dans le kernel (contrairement à /dev/kmem ). Avoir access à de la memory brute qui peut être potentiellement abusée / exploitée me semble être juste une request de problèmes.

Y a-t-il un usage pratique pour cela? Est-ce que les programmes user exigent que cela fonctionne correctement?

Il y a un jeu de diapositives de Scale 7x 2009 intitulé: Miner le kernel Linux: Injection de code malveillant via / dev / mem qui contenait ces 2 balles.

Qui a besoin de ça?

  • X Server (memorys video et registres de contrôle)
  • DOSEmu

De tout ce que j'ai trouvé à partir de la search jusqu'à présent, il semblerait que ces 2 balles soient les premiers à utiliser légitimement.

Les references

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

Comme vous le savez, /dev/mem donne access à la memory physique d'un système en cours d'exécution. /dev/kmem donne access à la memory virtuelle du kernel. Ces deux périphériques de caractères peuvent être désactivés de manière persistante via les options de configuration du kernel (le code est la source d'information la plus fiable, de sorte qu'il est utilisé comme reference). L'annulation des deux premières options ci-dessous désactivera les périphériques correspondants.

  • CONFIG_DEVKMEM : détermine si /dev/kmem est créé au démarrage
  • CONFIG_DEVMEM : détermine si /dev/mem est créé au démarrage
  • CONFIG_STRICT_DEVMEM : si /dev/mem existe, détermine si l'access est restreint

Selon votre dissortingbution, votre configuration actuelle du kernel peut être vue en utilisant quelque chose comme zless /proc/config.gz ou 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 memory . Les implications de security négatives évidentes de disposer de ces périphériques virtuels disponibles (par exemple, un attaquant pouvant à la volée patcher la memory d'un autre process ou même du kernel) sont connus depuis au less une décennie. La ressortingction de l'access à /dev/mem a été prise en charge dans le kernel de la ligne principale depuis début 2008 , /dev/kmem a également été optionnel depuis l'époque .

Il y a une dizaine d'années, il semble que X dépendait de /dev/mem , je ne pense pas que ce soit toujours vrai. Pour tester les revendications concernant X nécessitant /dev/mem j'ai supprimé le périphérique virtuel de mon ordinateur portable hier et cela fonctionne parfaitement depuis. En 2017, il semble n'y avoir aucune utilisation pratique de ces appareils en dehors de la search et du développement.

Du sharepoint vue de la security, il est recommandé de supprimer ces périphériques. Il est toujours intéressant de noter qu'un attaquant distant , avec des privilèges élevés, peut lire de la memory en dehors de son espace d'adressage. La memory des autres applications d'espace user peut être accédée en utilisant /proc/<pid>/mem . La memory du kernel peut être accédée en utilisant /proc/kcore .

Il vaut la peine de noter que même si vous avez désactivé /dev/mem et /dev/kmem cette memory peut encore être vidée; jetez un oeil à man proc pour révéler /proc/kcore ; c'est la memory physique des systèmes. Un très bon outil d' parsing médico-légale rekall dispose d'un outil qui le fait déjà ; il décharge la memory (et /boot files) afin qu'ils puissent être analysés.

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

Il n'y a pas d'utilisation moderne de /dev/kmem au-delà des attaquants qui l'utilisent pour charger les rootkits du kernel. CONFIG_DEVKMEM est défini sur "n". Bien que le nœud périphérique /dev/kmem existe toujours dans Ubuntu 8.04 LTS via Ubuntu 9.04, il n'est en fait attaché à rien du kernel.

Ubuntu ne désactive pas /dev/mem parce que c'est nécessaire pour les applications .

Certaines applications (Xorg) ont besoin d'un access direct à la memory physique depuis l'espace user. Le file spécial /dev/mem existe pour fournir cet access. Dans le passé, il était possible de voir et de changer la memory du kernel de ce file si un attaquant avait un access root. L'option de kernel CONFIG_STRICT_DEVMEM été introduite pour bloquer l'access à la memory sans périphérique (à l'origine nommé CONFIG_NONPROMISC_DEVMEM ).

Comment désactiver /proc/kcore ?

N'activez pas CONFIG_PROC_KCORE lors de la construction du kernel.

Comment désactivez-vous /dev/mem ?

Eh bien, regarder par-dessus l' man mem 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 être capable de simplement rm -rf /dev/mem ; vous pouvez désactiver pendant la phase de construction du kernel en CONFIG_STRICT_DEVMEM pas CONFIG_STRICT_DEVMEM .

Comment désactiver /dev/kmem ?

Assurez-vous que CONFIG_DEVKMEM n'est pas activé lors de la génération du kernel.

Comment prévenir les attaques par démarrage à froid?

Que se passe-t-il si je pouvais désactiver /proc/kcore , /dev/mem , /dev/kmem et que /dev/kmem une partition swap chiffrée ou n'utilisais pas de swap du tout? Eh bien, votre memory pourrait être gelée et accessible de cette façon. Comment préviens-tu cette attaque? Vous cryptez votre RAM; comment crypter votre RAM? Tu ne peux pas. Voir TRESOR pour plus de détails .