Kernel: Deaktivieren von / dev / kmem und / dev / mem

Ich verstehe das /dev/kmemund /dev/membiete Zugriff auf den Speicher (dh den Roh-RAM) des Systems. Mir ist auch bewusst, dass /dev/kmemdies im Kernel vollständig deaktiviert werden kann und dass der Zugriff für eingeschränkt werden kann /dev/mem.

Es scheint mir, roh Zugriff auf Speicher kann für Entwickler und Hacker nützlich sein, aber warum soll ich auf dem Speicher durch Zugriff benötigen /dev/mem. AFAIK kann im Kernel nicht deaktiviert werden (im Gegensatz zu /dev/kmem). Der Zugriff auf unformatierten Speicher, der möglicherweise missbraucht / ausgenutzt werden kann, scheint mir nur um Ärger zu bitten.

Gibt es eine praktische Verwendung dafür? Benötigen Benutzerprogramme eine ordnungsgemäße Funktion?

Es gibt ein Dia-Deck von Scale 7x 2009 mit dem Titel: Untergrabung des Linux-Kernels: Injection von bösartigem Code über / dev / mem , das diese beiden Aufzählungszeichen enthielt.

Wer braucht das?

• X Server (Videospeicher- und Steuerregister)
• DOSEmu

Nach allem, was ich bisher bei der Suche gefunden habe, scheinen diese beiden Kugeln die Spitzenreiter für legitime Zwecke zu sein.

Verweise

• Anthony Lineberry auf / dev / mem Rootkits - LJ 8/2009 von Mick Bauer
• Wer braucht / dev / kmem?

Es ist erwähnenswert, dass selbst wenn Sie deaktiviert /dev/memund /dev/kmemdass der Speicher noch abgeladen werden kann; werfen Sie einen Blick auf man proc, um zu enthüllen /proc/kcore; Es ist der physische Speicher des Systems. Ein wirklich gutes Forensik-Toolkit rekall hat ein Tool, das dies bereits tut . Es speichert den Speicher (und die /bootDateien), damit sie analysiert werden können.

Tatsächlich deaktiviert Ubuntu standardmäßig/dev/kmem :

Es gibt keine moderne Verwendung /dev/kmemmehr als Angreifer, die es zum Laden von Kernel-Rootkits verwenden. CONFIG_DEVKMEMist auf "n" gesetzt. Während der /dev/kmemGeräteknoten in Ubuntu 8.04 LTS bis Ubuntu 9.04 noch vorhanden ist, ist er an nichts im Kernel gebunden.

Ubuntu wird nicht deaktiviert, /dev/memda es von Anwendungen benötigt wird .

Einige Anwendungen (Xorg) benötigen direkten Zugriff auf den physischen Speicher aus dem Benutzerbereich. Die spezielle Datei ist /dev/memvorhanden, um diesen Zugriff zu ermöglichen. In der Vergangenheit war es möglich, den Kernelspeicher dieser Datei anzuzeigen und zu ändern, wenn ein Angreifer Root-Zugriff hatte. Die CONFIG_STRICT_DEVMEMKernel-Option wurde eingeführt, um den Speicherzugriff auf Geräte zu blockieren (ursprünglich benannt CONFIG_NONPROMISC_DEVMEM).

Wie deaktiviere ich /proc/kcore?

CONFIG_PROC_KCOREBeim Erstellen des Kernels nicht aktivieren .

Wie deaktivierst du /dev/mem?

Wenn man memwir uns das ansehen, erfahren wir einige Details darüber, wie es erstellt wurde:

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

Sie sollten in der Lage sein, nur rm -rf /dev/mem; Sie können während der Kernel-Build-Phase deaktivieren, indem Sie nicht aktivieren CONFIG_STRICT_DEVMEM.

Wie deaktiviere ich /dev/kmem?

Stellen Sie sicher, dass CONFIG_DEVKMEMdies beim Erstellen des Kernels nicht aktiviert ist.

Wie kann man Kaltstartangriffe verhindern?

Was passiert , wenn ich zu deaktivieren war in der Lage /proc/kcore, /dev/mem, /dev/kmemund dann eine verschlüsselte Swap - Partition oder nicht genutzt Swap überhaupt verwendet? Nun, Ihr Gedächtnis könnte einfach eingefroren und auf diese Weise abgerufen werden. Wie verhindern Sie diesen Angriff? Sie verschlüsseln Ihren RAM. Wie verschlüsseln Sie Ihren RAM? Das kannst du nicht. Siehe TRESOR für Details .

Wie Sie wissen, /dev/membietet es Zugriff auf den physischen Speicher eines laufenden Systems. /dev/kmemBietet Zugriff auf den virtuellen Kernelspeicher. Diese beiden Zeichengeräte können durch Kernel-Konfigurationsoptionen dauerhaft deaktiviert werden (der Code ist die maßgeblichste Informationsquelle und wird daher als Referenz verwendet). Durch Deaktivieren der ersten beiden Optionen werden die entsprechenden Geräte deaktiviert.

• CONFIG_DEVKMEM: Bestimmt, ob /dev/kmembeim Booten erstellt wird
• CONFIG_DEVMEM: Bestimmt, ob /dev/membeim Booten erstellt wird
• CONFIG_STRICT_DEVMEM: Wenn /dev/memvorhanden, wird festgelegt, ob der Zugriff darauf eingeschränkt ist

Abhängig von Ihrer Distribution kann Ihre aktuelle Kernelkonfiguration mit etwas wie zless /proc/config.gzoder angezeigt werden less /boot/config-$(uname -r).

Ich denke, die ursprüngliche Absicht von /dev/memwar es, die Interaktion mit Peripheriegeräten mit Speicherzuordnung zu unterstützen . Die offensichtlichen negativen Auswirkungen der Verfügbarkeit dieser virtuellen Geräte auf die Sicherheit (z. B. wenn ein Angreifer in der Lage ist, den Speicher eines anderen Prozesses oder sogar des Kernels im laufenden Betrieb zu patchen) sind seit mindestens einem Jahrzehnt bekannt. Einschränken des Zugriffs auf /dev/memhat in den Mainline - Kernel unterstützt seit Anfang 2008 , /dev/kmemhat auch optional gewesen , da um dann auch.

Vor einem Jahrzehnt schien das Xabhängig zu sein /dev/mem, ich glaube nicht, dass dies immer noch wahr ist. Um die Behauptungen über die XNotwendigkeit zu testen , habe /dev/memich gestern das virtuelle Gerät von meinem Laptop gelöscht und es funktioniert seitdem scheinbar perfekt. Im Jahr 2017 scheint es keine praktische Verwendung für diese Geräte außerhalb der Forschung und Entwicklung zu geben.

Aus Sicherheitsgründen empfiehlt es sich, diese Geräte zu entfernen. Es ist noch erwähnenswert, dass ein Remote - Angreifer, mit erhöhten Rechten, Speicher außerhalb seines Adressraumes lesen kann. Auf den Speicher anderer User Space-Anwendungen kann mit zugegriffen werden /proc/<pid>/mem. Auf den Kernel-Speicher kann mit zugegriffen werden /proc/kcore.

Ich habe /dev/memvon Anfang an nicht in mein System aufgenommen. Ich verwende Gentoo Linux, daher ist dies keine Überraschung, da Sie mit dieser Linux-Distribution praktisch jedes Paket selbst erstellen, einschließlich des Linux-Kernels.

Ich habe keine Probleme aufgrund des Mangels an /dev/memX.org X11 bemerkt . Erst heute habe ich festgestellt, dass ein Auftauchen des Pakets x11-drivers/xf86-video-vesaeine Meldung druckt, die besagt, dass es erforderlich ist /dev/mem, wie folgt:

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

Da ich den VESA-Treiber für den XServer nicht absichtlich oder auch nur als Fallback installiert habe, musste ich ihn eigentlich nie verwenden und habe ihn daher bisher nicht bemerkt.

Dies beweist jedoch, dass a) X11 nicht mehr benötigt /dev/memwird und b) einige X11-Grafiktreiber dies möglicherweise trotzdem tun.

Neuere Videotreiber für bestimmte Hardware funktionieren höchstwahrscheinlich ohne diese. Genau wie das moderne X.org-X11 (auf Gentoo x11-base/xorg-server) nicht einmal mehr suid root sein muss, sieht Fortschritt so aus ...