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.
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 kernelCONFIG_STRICT_DEVMEM
été introduite pour bloquer l'access à la memory sans périphérique (à l'origine nomméCONFIG_NONPROMISC_DEVMEM
).
/proc/kcore
? N'activez pas CONFIG_PROC_KCORE
lors de la construction du kernel.
/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
.
/dev/kmem
? Assurez-vous que CONFIG_DEVKMEM
n'est pas activé lors de la génération du kernel.
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 .