RootForum Community

Wer lokale Shell-User auf seinem Rootie hat, sollte schnellstens über ein Kernel-Update nachdenken :
http://www.securityfocus.com/archive/1/ ... 03-03-23/0

Systeme, die ptrace per GRSecurity deaktivieren sind nicht betroffen ...

hmm gibts scho irgendwo n how to zwecks kernel update bei nem rooti?

ich glaub vom kernel lass ich lieber die finger da hab ich bisher noch nciht wirklich viel mit gemacht ;)

Entweder wartest du auf die Updates des Distributors deines geringstens Misstraunes, oder nimmst z.B. diese hier : http://www.rootforum.org/faq/index.php? ... =010&id=45

noch hat SuSE leider nix im Angebot......

Paulchen

nunja die rooties haben ja nen anderen kernel als die suse original version deswegen bin ich mir nicht sicher ob ein suse patch das geht?!

Das ist ne gute Frage, mir hat 1und1 auch den aktuellen 2.4.20er drauf. Gibt es die 1und1-Kernels eigentlich auch irgenwo? Gebaut werden sie ja, so wie es aussieht...

phisch

Falls ihr den Link noch nicht gelesen habt :

Solutions/workarounds:
- patch the kernel
or
- disable kmod/modules
or
- install a ptrace-blocking module
or
- set /proc/sys/kernel/modprobe to /any/bogus/file

Die Möglichkeit ganz unten ist so ziemlich das schnellste, was man machen kann, da auf Rooties wohl kaum jemand so extensiv mit Modulen rumspielen wird ...

>- set /proc/sys/kernel/modprobe to /any/bogus/file

???

bedeutet dass einfach:

mv /proc/sys/kernel/modprobe /proc/sys/kernel/modprobe.irgendwas

und fertig ?

Modprobe brauch ich doch nur, um zu testen, ob ein kernelmodul geladen ist, oder ? Hätte ich durch diese Methode noch andere Nachteile ?

Ich sag doch immer kein Module Support aufm Root-Server. Macht ja auch kein Sinn, da sich die Hardware nie ändert...

kase wrote:>- set /proc/sys/kernel/modprobe to /any/bogus/file
bedeutet dass einfach:

mv /proc/sys/kernel/modprobe /proc/sys/kernel/modprobe.irgendwas

und fertig ?

In einem anderen Forum habe ich gelesen, dass bedeutet, man müsse irgendeine leere Datei in modprobe schreiben, also so:

cat /pfad/leere.datei > /proc/sys/kernel/modprobe

Was genau muss man denn nun tun ?

Was genau muss man denn nun tun ?

echo /nix > /proc/sys/kernel/modprobe

damit ist man gegen den exploit erstmal geschützt.
man sollte aber bevor man rebootet die alten daten wieder reinschreiben.
echo /sbin/modprobe > /proc/sys/kernel/modprobe

v00dY wrote:

Was genau muss man denn nun tun ?

echo /nix > /proc/sys/kernel/modprobe

damit ist man gegen den exploit erstmal geschützt.
man sollte aber bevor man rebootet die alten daten wieder reinschreiben.
echo /sbin/modprobe > /proc/sys/kernel/modprobe

Hmmmm, bin zwar neu in dem Gebiet aber was ich nicht verstehe ist, was ändert sich, wenn ich erst das File ändere und dann wieder "die alten Daten reinschreibe" ??

Es geht IMHO darum dass es sonst bei einem reboot des Systems zu Problemen kommen kann... nach einem Neustart musst du den "Fix" natürlich erneut anwenden!

nach einem Neustart musst du den "Fix" natürlich erneut anwenden!

Eben drum ist ein Kernel-Update ja auch angeraten ...

Für Debian gibts aber noch keins ;)

Für Debian gibts aber noch keins

Sofern du GRSecurity drauf hast, brauchst du dir sowieso keine Sorgen machen. Ich hab den Exploit gestern mal auf ein paar (meiner eigenen ) Kisten ausprobiert. Ist schon krass, daher bin ich auch immer mehr von GRSecurity überzeugt ...

nee, ich habe keinen GRSecurity drauf. Habe auch keine weiteren SSH User. Trotzdem habe ich ein ungutes Gefühl, ein Sicherheitsloch zu haben, auch wenns keiner nutzen kann :D

Du brauchst keinen Shelluser... es gibt bereits ein CGI Script das die Lücke ausnützt

ja, aber für das CGI Script brauchst du doch SSH Access um es auszuführn oder es auf den webspace hochzuladen...

Ist bei GRSecurity der Bug schon fixed, oder kann man da bloß die Sicherheitslücke nicht ausnutzen, weil GRSecurity das nicht zulässt?

P.S. Hab auch den grsec kernel patch drauf *g*

Dort kann man sooviel ich weiß ptrace deaktivieren, dass heißt, eine Funktion, die gebraucht wird, ist gesperrt. Allerdings musst du diese bei den Settings auch gesperrt haben...

Ist bei GRSecurity der Bug schon fixed, oder kann man da bloß die Sicherheitslücke nicht ausnutzen, weil GRSecurity das nicht zulässt?

Je nachdem, wie du den Patch kompiliert hast, lässt du ptrace einfach nicht zu, was den Erfolg des Exploits zunichte macht ...

Falls du die Option nicht mit drin hast (nachzuschauen unter /proc/sys/kernel/grsecurity/usw ...) kann die Lücke immer noch ausgenutzt werden ...

CaptainCrunch wrote:Falls ihr den Link noch nicht gelesen habt :

Solutions/workarounds:
- patch the kernel
or
- disable kmod/modules
or
- install a ptrace-blocking module
or
- set /proc/sys/kernel/modprobe to /any/bogus/file

Die Möglichkeit ganz unten ist so ziemlich das schnellste, was man machen kann, da auf Rooties wohl kaum jemand so extensiv mit Modulen rumspielen wird ...

Würds du dafür wetten, dass das reicht? Gib mir doch mal kurz nen Account auf Deiner Kiste. :-)

Naja, vielleicht klappt es mit GRSecurity nicht.

[TOM]

Würds du dafür wetten, dass das reicht? Gib mir doch mal kurz nen Account auf Deiner Kiste.

In dem Fall würde ich ... hab's schon den einen oder anderen Test hinter mir ...

kase wrote:ja, aber für das CGI Script brauchst du doch SSH Access um es auszuführn oder es auf den webspace hochzuladen...

Nein, FTP oder sonstwas womit man Daten auf den Server bekommt reicht.