#1 31. August 2009 Hallo zusammen, mich würde mal interessieren, ob für Linux Kernels ab Version 2.6.21 funktionsfähige Rootkits bekannt sind? Die dabei eingesetzte Methode ist egal. Die meisten public Rootkits sind meist mehrere Jahre alt und wurden logischerweise auf entsprechende Kerneländerungen nicht upgedatet. Funktioniert die /dev/(k)mem Methode denn noch weiterhin für aktuelle Kernel, so fern das Device für root schreibbar ist? Oder gibt es aktualisierte LKM-Ansätze? Grüße + Multi-Zitat Zitieren
#2 31. August 2009 AW: Rootkits für Linux Kernel ab 2.6.21? Hoi, soweit ich weiß gibts keine Rootkits (zumindest keine die public sind), welche noch funktionieren. Die Möglichkeit /proc zu patchen funktioniert auch seit einigen Versionen nicht mehr (da proc_root nicht mehr exportiert wird). Vllt. klappt das mit /dev/kmem noch, aber man müsste die alten rootkits wahrscheinlich alle anpassen. Was aber noch klappt sind userland-rootkits, z.b. einfach shared librarys die mittels dem LD_PRELOAD funktionen überschreiben können. natürlich nicht ganz so effektiv wie kernelmode rootkits, dafür leichter zu programmieren. und für viele administratoren ausreichend. + Multi-Zitat Zitieren
#3 31. August 2009 Vielen Dank dür deine Antwort. Ich denke, dass es seit der Einführung von CONFIG_STRICT_DEVMEM (bei neueren Kernel von diversen Distributionen afair sogar per default an) nicht mehr bzw. schwierig möglich ist, den Kernel über /dev/mem mit eigenem Schadcode zu infizieren. (Es wird der Speicher, in welchem sich der Kernel befindet, geblockt.) Bzgl LKM-Rootkit: Was hat sich denn ab 2.6.21.x / 2.6.22 geändert (Release immerhin Juli 2007 laut kernel.org), so dass man bei einem LKM-Rootkit nicht mehr an die Adressen der sys_call_table im Kernel Memory herankommt, um so interne Kernel-Funktionen auszutauschen? Sind hier ebanfalls irgendwelche Schutzmechanismen im Einsatz? Um meine Frage selbst zu beantworten: Die Adresse bekommt man schon noch heraus, jedoch ist der Datensektor der sys_call_table schreibgeschützt: Code: // arch/x86/kernel/entry_32.S .section .rodata,"a" // readonly #include "syscall_table_32.S" syscall_table_size=(.-sys_call_table) Es gibt aber Workarounds bzw. andere Ansätze, die den Schreibschutz umgehen können. edit (pyro): Beiträge zusammengeführt. + Multi-Zitat Zitieren