0-Day-Exploit ermöglicht root-Rechte: Linux-Kernel 2.6.x betroffen
Posted: 2006-07-16 01:14
Resources for System-Administrators
https://www.rootforum.org/forum/
Code: Select all
user@linux:~> gcc
-bash: /usr/bin/gcc: Keine Berechtigung
wenn man's nicht compilieren kann wird's auch nicht laufen. :lol: Aber was spricht dagegen auf einer anderen Kiste zu compilieren und direkt das Binary hochzuladen?blnsnoopy26 wrote:Ob es auch funzt, wenn gcc generell verboten is für ottonormal User?
Stimmt auch wieder , aber ist mir hinterher dann auch eingefallen :-Dwgot wrote:Hallo,
wenn man's nicht compilieren kann wird's auch nicht laufen. :lol: Aber was spricht dagegen auf einer anderen Kiste zu compilieren und direkt das Binary hochzuladen?blnsnoopy26 wrote:Ob es auch funzt, wenn gcc generell verboten is für ottonormal User?
Gruß, Wolfgang
Nicht erfreulich? Sicherlich, aber irgendwo war's ja auch nicht anders zu erwarten. Immerhin kommt es ja groß in Mode, sich mal eben einen Linux-Server zu ordern. Ob man Ahnung davin hat oder nicht ist ja egal, Confixx, Plesk etc. regeln ja schließlich alles.Ich finde es nicht besonders erfreulich daß am gleichen Tag an dem der Bugfix verfügbar ist eine idiotensichere Anleitung veröffentlich wird die jeder Webspacekunde mit SSH im Paket mal eben abtippen kann und dann auch noch den Hinweis wegzulassen daß gefixte Kernelsourcen verfügbar sind.
ich habs gestern noch ausprobiert :-(blnsnoopy26 wrote:im im grsec /proc restriction einkompiliert wurde...
Habs noch nicht ausprobiert, daher frage ich hier mal.
Code: Select all
Linux linux 2.6.17.6-default #1 Sun Jul 16 10:53:38 CEST 2006 i686 athlon i386 GNU/Linux
Wo kriegt man diese Kernel-Sourcen eigentlich her, wenn man kein Gentoo benutzt? Nur mal so am Rande ...zg0re wrote:Also bei mir hatte der exploit nicht funktioniert mit 2.6.14-hardened von gentoo
Für diesen Exploit braucht man das, aber zum Ausnutzten der Sicherheitslücke nicht...Spasswolf wrote:Für den Exploit braucht man ja aout Unterstützung im Kernel, gibt es eigentlich irgendwelche Programme für die man die noch braucht ?
da sind mir zuhause schon ein paar andere Ausdrücke rausgerutscht, aber die passen nicht in in seriöses Forum. :roll:CaptainCrunch wrote:Nicht erfreulich?
wie schnell?Wohl dem, der momentan auf die stinknormalen Kernelpakete seiner Distribution setzt, immerhin übernehmen die das bauen für einen.
Code: Select all
AOUT=m
Der Spezialist mit Linux 8.0 und 40 Kunden hat zumindest das heute diskutierte Problem nicht, der müßte Kernel 2.4 haben. :lol:"Hilfe, mein Server wurde gehackt"-Welle
... wenn er das Problem noch nicht behoben hat, hat er wohl auch keine 40 Kunden mehr ...wgot wrote:Der Spezialist mit Linux 8.0 und 40 Kunden hat zumindest das heute diskutierte Problem nicht, der müßte Kernel 2.4 haben. :lol:
Die Unterstützung des a.out Format hat nichts mit der Sicherheitslücke zu tun. Wenn du dich dadurch sicherer fühlst ->wgot wrote: Auf dem Updateserver eines (auch hier) sehr bekannten Providers liegt erfreulicherweise seit gestern ca. 19 Uhr ein fertig compilierter 2.6.17.5 bereit, ich hab ihn mal ausgepackt und die config angesehen::oops:Code: Select all
AOUT=m
Code: Select all
find / -type f binfmt_aout.ko | xargs rm -fMit 2.6.17.5 läuft der Patch von grsec zumindest durch. Aber von grsec gibt es auch schon lange keine "offizielle" Versionen mehr. Irgendwie auch nicht gerade vertrauenserweckend. Aber bei der schnellen Kernel-Entwicklung auch kein Wunder.blnsnoopy26 wrote:Ich habe jetzt mir ein neuen Kernel gebacken und läuft jetzt mit dem neuen, aber leider ohne grsec :?
Aber immer noch besser als mit dem Exploit zu leben.Code: Select all
Linux linux 2.6.17.6-default #1 Sun Jul 16 10:53:38 CEST 2006 i686 athlon i386 GNU/Linux
Funzt das Kompilieren selbst auch und bootet der Kernel dann auch?Athlux wrote:Mit 2.6.17.5 läuft der Patch von grsec zumindest durch. Aber von grsec gibt es auch schon lange keine "offizielle" Versionen mehr. Irgendwie auch nicht gerade vertrauenserweckend. Aber bei der schnellen Kernel-Entwicklung auch kein Wunder.blnsnoopy26 wrote:Ich habe jetzt mir ein neuen Kernel gebacken und läuft jetzt mit dem neuen, aber leider ohne grsec :?
Aber immer noch besser als mit dem Exploit zu leben.Code: Select all
Linux linux 2.6.17.6-default #1 Sun Jul 16 10:53:38 CEST 2006 i686 athlon i386 GNU/Linux
Also bei mir bootet der Rechner danach wieder problemlos.Funzt das Kompilieren selbst auch und bootet der Kernel dann auch?
Weil dann würde ich mir 2.6.17.5 + grsec installieren.
Riskantes unterfangen, weil ich keine Remotekonsole habe, fals er dann doch nicht mehr hochkommt und dann wirds teuer für mich.Athlux wrote:Also bei mir bootet der Rechner danach wieder problemlos.Funzt das Kompilieren selbst auch und bootet der Kernel dann auch?
Weil dann würde ich mir 2.6.17.5 + grsec installieren.
Wird auch teilweise auf deine Kernel-Optionen ankommen.
mv linux-2.6.17.6 linux-2.6.17.4
patch -p0 --dry-run grsecurity-2.1.9-2.6.17.4-200607120947.patch
Den Patch findet man unter
http://www.grsecurity.net/~spender/
Bei mir bootet das System dann wie schon gesagt problemlos wieder hoch. Laut Forum sollte man aber nicht "Prevent invalid userland pointer dereference" aktiviert haben, da scheint es noch Probleme geben.
schon klar, mir ging's um etwas ganz anderes: wie das Beispiel mit dem Providerkernel zeigt sind es eben nicht nur ein paar ungepflegte Server auf denen der Exploit nach dem Kochrezept funktioniert sondern eine ganze Menge. Ich gehe davon aus daß ein großer Teil der Kunden (sofern er überhaupt regelmäßig updatet) den Service dankbar annimmt.oxygen wrote:Die Unterstützung des a.out Format hat nichts mit der Sicherheitslücke zu tun.
So an einem Stück nicht... Auf den Gentoo-Servern stehen die Sourcen für den 2.6.16 bereit, zusammen mit zwei Patch-Paketen:flo wrote:Wo kriegt man diese Kernel-Sourcen eigentlich her, wenn man kein Gentoo benutzt? Nur mal so am Rande ...
Code: Select all
linux-2.6.16.tar.bz2
hardened-patches-2.6.16-8.extras.tar.bz2
genpatches-2.6.16-14.base.tar.bz2Falls du lilo benutzt kannst du mit "lilo -R kernelname" dafür sorgen das der neue Kernel explizit nach dem nächsten Reboot gestartet wird.blnsnoopy26 wrote: Riskantes unterfangen, weil ich keine Remotekonsole habe, fals er dann doch nicht mehr hochkommt und dann wirds teuer für mich.
Das ist bei den PAX-Features als Option zu finden. Versteckt sich hinter dem Menüpunkt "Miscellaneous hardening features --->"blnsnoopy26 wrote: Wo wird das "Prevent invalid userland pointer dereference" aktiviert/deaktiviert? in den grsec einstellungen finde ich dazu nichts.
Ich benutze Grub als Bootloader, also kommt dies nicht für mich in frage. Der Reset ist kostenlos, nur wenn ich meinem Hoster sagen muss, das er den anderen Kernel wieder einbinden muss, dann kostet mich das 15 € / 30 Min. (Remote Hand)Athlux wrote:Falls du lilo benutzt kannst du mit "lilo -R kernelname" dafür sorgen das der neue Kernel explizit nach dem nächsten Reboot gestartet wird.blnsnoopy26 wrote: Riskantes unterfangen, weil ich keine Remotekonsole habe, fals er dann doch nicht mehr hochkommt und dann wirds teuer für mich.
Sollte der nicht Booten reicht ein einfaches Reset und der Alte bootet wieder.
Für grub gibts es imho keine solche Option.
Ich hoffe doch dein Hoster stellt dir einmal auf den "Reset" Knopf drücken nicht gleich in Rechnung. Der Nachteil ist aber wenn du kein Automatisches-Reset hast bist du auf die Support-Zeiten des Hosters angewiesen.
Das ist bei den PAX-Features als Option zu finden. Versteckt sich hinter dem Menüpunkt "Miscellaneous hardening features --->"blnsnoopy26 wrote: Wo wird das "Prevent invalid userland pointer dereference" aktiviert/deaktiviert? in den grsec einstellungen finde ich dazu nichts.
Danke - das kann ich mir je gleich mal anschauen ... :-)jfreund wrote:[EDIT 2] Hab die hardened Kernel-Sourcen mal emerged und dann in ein Archiv gepackt. Steht unter ftp.my-universe.com zum downloaden bereit.