Sicherheitsloch im Linux Kernel

[gfc]

Sicherheitsloch im Linux-Multiuser-Betrieb

Der Kern des Betriebssystems Linux enthält einen Fehler, der es lokalen Benutzern erlaubt, auf dem System Root-Rechte zu erlangen. Betroffen sind die Kernel-Versionen 2.2 und 2.4 und damit nahezu alle Linux-Systeme, die seit 1999 installiert wurden, und bei denen der Administrator die Möglichkeit, Kernel-Module nachträglich zu laden, nicht explizit abgeschaltet hat. Es existiert auch bereits ein fertiger Demo-Exploit, der einem Angreifer direkt eine Shell mit Root-Rechten beschert.


Allerdings lässt sich der Fehler nicht ohne direkten Zugang -- also remote von einem beliebigen anderen System aus -- ausnutzen; der Angreifer muss also bereits einen Zugang auf dem attackierten Computer haben. Wo Linux also im Multiuser-Betrieb genutzt wird, sollten Administratoren schleunigst ein Kernel-Update einspielen. Auf Servern, auf denen regulär nur Adminstratoren Zugang haben, ist die Lücke nicht ganz so ernst; man sollte jedoch auch dort den Patch einspielen und sich gegen den Fall absichern, dass ein anderes Sicherheitsloch Angreifern einen Zugang mit eingeschränkten Rechten ermöglicht, der dann über den Kernel-Bug sofort zur Root-Shell ausgebaut werden könnte.


Auf dem zentralen Kernel-Archiv steht ein Patch für die Version 2.2 bereit; Red Hat bietet bereits Kernel-Updates für 2.4er-Kernel (Red Hat 7.x, 8.0).


Der Bug beruht darauhttp://www.heise.de/newsticker/data/ju-20.03.03-000/f, dass der Kernel das Nachladen von Modulen nicht ausreichend gegen externe Modifikationen absichert. So kann man über die Debug-Funktion ptrace() die Kontrolle über einen Prozess erlangen, der ein Modul nachladen soll und dort beliebigen eigenen Code einschleusen. Dieser wird dann mit Root-Rechten ausgeführt. (ju/c't)

hier die Quelle: http://www.heise.de/newsticker/data/ju-20.03.03-000/

[Hotspott]

Und wie dichte ich nun mein Debian woody ab?

[Sayonara]

Für alle, die es noch nicht wissen. Bitte beachten:
http://www.heise.de/newsticker/data/ju-20.03.03-000/

[DerLipper[TuX]]

naja wurde schon vor Monaten im IRC diskutiert...:D

[derRichard]

Original geschrieben von Sayonara
Für alle, die es noch nicht wissen. Bitte beachten:
http://www.heise.de/newsticker/data/ju-20.03.03-000/
hallo!

bei pro-linux war es auch schon:
http://www.pro-linux.de/news/2003/5329.html

ich wundere mich nur warum es noch nicht bei rus-cert gekommen ist.

//richard

[hunter]

JETZT REICHTS MIR ABER !!!

Linux ist sowas von unsicher. Jetzt ists genug, ich geh zurück nach Windows !!!


Öh. Wir haben ja noch gar nicht den 1. April ... (wollte auch mal trollen :) )


Ok, nun ernsthaft weiter:

Man wird wohl seinen Kernel auf ein entsprechend neues Release oder Version updaten oder sich einen eigenen Kernel compilieren müssen.

Der Aufwand lohnt aber nur dann wenn überhaupt Leute an den Rechner dran kommen um ihn modifizieren zu können.

[real-challo]

Guck mal hier :

http://www.linuxforen.de/forums/showthread.php?s=&threadid=71485

[derRichard]

Original geschrieben von real-challo
Guck mal hier :

http://www.linuxforen.de/forums/showthread.php?s=&threadid=71485
so ein rekursiver link is zwar recht witzig aber zu welchem zweck? :rolleyes:

//richard

[real-challo]

Original geschrieben von derRichard
so ein rekursiver link is zwar recht witzig aber zu welchem zweck? :rolleyes:

//richard

Ich wollte damit dagen , dass es hier schon diskuttiert wird.

Aber tröste Dich - inzwischen habe ich noch einen Beitrag gefunden, wo der gleich Link steht - also 3x das gleiche ?????

[msi]

so, alle die eine vorübergehende Lösung für dieses Problem suchen:



/*
while waiting for kernel compilations from Debian (and while waiting
for my kernel compilations to finish), I coded a single module,
which acts as a workaround for one particular exploit I found in one
user's homedirectory.

Disclaimer:

1.) I don't guarantee, that it will protect you from other
exploits (it won't).

2.) I guarantee, it won't break anything (actually it will break
some occassional ptrace situations, but for simple gdb and stuff,
this is ok).

3.) I don't guarantee it will work. It may freeze your machine.
YMMV.

4.) I'm not a linux kernel module coder. If you'll come with
something better, drop me a note.

5.) Against this exploit, simple chmod 700 /proc would suffice
(since it wants to open /proc/self/exe). This is somehow cleaner.

6.) It should unload correctly, if it won't freeze your system
(see point 3:).

Anyways, as a simple workaround, it works.

Compile with

gcc -o ptrace_workaround.o -c ptrace_workaround.c -I/usr/src/linux/include

(/usr/src/linux should compile preconfigured kernel headers, or include
from kernel-headers package).

*/
#define MODULE
#define __KERNEL__
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/modversions.h>
#include <linux/smp_lock.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/sched.h>
#include <sys/syscall.h> /* The list of system calls */

MODULE_LICENSE("GPL");

extern void *sys_call_table[]; /*sys_call_table is exported, so we can access it */


int (*orig_sys_ptrace)(long request, long pid, long addr, long data);

#define is_dumpable(tsk) ((tsk)->task_dumpable && (tsk)->mm->dumpable)

int
hacked_sys_ptrace (long request, long pid, long addr, long data)
{
struct task_struct *child;

lock_kernel();

read_lock(&tasklist_lock);
child = find_task_by_pid(pid);
if (child)
get_task_struct(child);
read_unlock(&tasklist_lock);
if (!child) {
unlock_kernel();
return -ESRCH;
}



if (request!=PTRACE_ATTACH) {
mb();
if ((child->euid!=child->uid) || (child->egid==child->gid))
{
unlock_kernel();
return -EPERM;
}
}
unlock_kernel();
orig_sys_ptrace(request, pid, addr, data);
}

int
init_module (void) /*module setup */
{
orig_sys_ptrace = sys_call_table[SYS_ptrace];
sys_call_table[SYS_ptrace] = hacked_sys_ptrace;
return 0;
}

void
cleanup_module (void) /*module shutdown */
{
sys_call_table[SYS_ptrace] = orig_sys_ptrace; /*set ptrace syscall to the origal one */
}


das ganze als Kernel Modul kompilieren:
gcc -o ptrace_workaround.o -c file.c -I/usr/src/linux/include
(der kernel muss mit dem selben gcc kompiliert worden sein und die sourcen des Linuxkernels sollten in /usr/src/linux/include liegen).
dannach mit insmod ptrace_workaround.o laden und man ist sicher ;-)

Angehängt hab ich auch noch einen Exploit zu diesem Bug, um die Lösung zu testen. Bitte nicht missbrauchen.... :rolleyes:

Gruß Markus

[hunter]

Gut. Compilieren , installieren und laden war erfolgreich.

Wenn ich nun dieses Script als User starte bekomme ich:

./km3
./km3: line 1: /bin: is a directory
./km3: line 2: km3: command not found
./km3: line 3: km3: command not found
./km3: line 4: km3: command not found
./km3: line 5: */: No such file or directory
./km3: line 22: //: is a directory
./km3: line 24: int: command not found
./km3: line 30: int: command not found
./km3: line 31: char: command not found
./km3: line 33: struct: command not found
./km3: line 34: int: command not found
./km3: line 35: int: command not found
./km3: line 37: //: is a directory
./km3: line 38: int: command not found
./km3: line 39: int: command not found
./km3: line 41: syntax error near unexpected token `('
./km3: line 41: `void killed(int a) { u2=1; }'


Bedeutet das das das nicht funktioniert weil das Modul es verhindert, oder ist das ein genereller Fehler ?

[Sonny]

der Workaround echo "" > /proc/sys/kernel/modprobe funzt nicht!

bei mir gehts immer noch
:~> ./a.out
sh-2.05b# id
uid=0(root) gid=0(root) Gruppen=0(root)

weil:
-rwsr-sr-x 1 root root 18803 2003-03-24 20:45 a.out
(s-bit)

[msi]

Original geschrieben von hunter
Gut. Compilieren , installieren und laden war erfolgreich.

Wenn ich nun dieses Script als User starte bekomme ich:

./km3
./km3: line 1: /bin: is a directory
./km3: line 2: km3: command not found
./km3: line 3: km3: command not found
./km3: line 4: km3: command not found
./km3: line 5: */: No such file or directory
./km3: line 22: //: is a directory
./km3: line 24: int: command not found
./km3: line 30: int: command not found
./km3: line 31: char: command not found
./km3: line 33: struct: command not found
./km3: line 34: int: command not found
./km3: line 35: int: command not found
./km3: line 37: //: is a directory
./km3: line 38: int: command not found
./km3: line 39: int: command not found
./km3: line 41: syntax error near unexpected token `('
./km3: line 41: `void killed(int a) { u2=1; }'


Bedeutet das das das nicht funktioniert weil das Modul es verhindert, oder ist das ein genereller Fehler ?

was ist den los mit dir hunter??
schau dir die km3.txt datei mal an, dann stellst du fest, dass das eine c-sourcedatei ist, die musst du zuerst noch kompilieren.

gcc km3.c
./a.out

edit: wunder dich nicht, wenn du keine root-shell kriegst, es wird lediglich das /usr/bin/id Programm mit root Rechten ausgeführt.

Gruß Markus

[hunter]

Thanks. Hatte mir das nicht näher angeschaut.

./a.out
Linux kmod + ptrace local root exploit by <anszom@v-lo.krakow.pl>

=> Simple mode, executing /bin/id > /dev/tty
sizeof(shellcode)=91
=> Child process started.

An dieser Stelle bleibt er stehen und führt id nicht aus. Entlade ich das Modul dann macht er es.


Und jetzt die Quizfrage: Reicht das ? Wenn ich den aktuellen Kernel beibehalte und beim booten das Modul laden lasse, wie sicher ist mein System nun ?

Dann dürfte ein Virus (ein theoretischer) doch eigentlich keinen Schaden mehr anrichten können da er zur Laufzeit nichts mehr auf diesem Wege ändern kann. Also kann er auch nichts einfügen was vor dem laden des Moduls beim booten ausgeführt werden könnte. Oder ?

[msi]

Original geschrieben von hunter
Und jetzt die Quizfrage: Reicht das ? Wenn ich den aktuellen Kernel beibehalte und beim booten das Modul laden lasse, wie sicher ist mein System nun ?

Dann dürfte ein Virus (ein theoretischer) doch eigentlich keinen Schaden mehr anrichten können da er zur Laufzeit nichts mehr auf diesem Wege ändern kann. Also kann er auch nichts einfügen was vor dem laden des Moduls beim booten ausgeführt werden könnte. Oder ?

ich hoffe, dass das reicht, der Exploit funktioniert nciht mehr, das heißt das dieser Angriff so nicht mehr funktioniert, ob man den variieren kann, weiß ich nicht, glaube allerdings nicht.
Für mich persönlich denke ich, dass er reicht (sollte keine Virengefahr mehr existieren). Für Produktivsysteme allerdings sollte man sich einmal den von Debian gepatchten Kernel oder den Kernelpatch von Alan (??) anschauen.

Gruß Markus

[RapidMax]

Ab 2.4.21-pre6 ist der Patch nun im Kernel (http://www.kernel.org/).

Gruss, Andy