0-Day-Exploit ermöglicht root-Rechte: Linux-Kernel 2.6.x betroffen

[baui1984]

Hallo,

Ist in 2.6.17.5 gefixt (seit gestern verfügbar).

Gruß, Wolfgang

Danke für den Hinweis, Wolfgang!
Seit ein paar Minuten läuft ein 2.6.17.6 bei mir... Mein erster selbst kompilierter Kernel. Ist ja garnicht so schwer :)
Hab nun aber trotzdem noch /proc mit nosuid und noexec gemountet. Sollte doch keine Probleme geben, oder hat jemand gegensätzliche Erfahrung sammeln müssen?

EDIT: Mit Kernel 2.6.17.6 und /proc/ mit default gemountet funktioniert es zumindest bei mir nicht... :)

[flo]

Hab nun aber trotzdem noch /proc mit nosuid und noexec gemountet. Sollte doch keine Probleme geben, oder hat jemand gegensätzliche Erfahrung sammeln müssen?

Im Gegenteil - ich habe das bei allen Rechnern jetzt so eingerichtet - Problem ist leider, daß ich erst Downtime hatte, weil ich meinen Webserver erst wieder auf RAID umgestellt habe - ich habe ein paar Kunden dabei, die das wirklich beobachten.

flo.

[baui1984]

Hab nun aber trotzdem noch /proc mit nosuid und noexec gemountet. Sollte doch keine Probleme geben, oder hat jemand gegensätzliche Erfahrung sammeln müssen?

Im Gegenteil - ich habe das bei allen Rechnern jetzt so eingerichtet - Problem ist leider, daß ich erst Downtime hatte, weil ich meinen Webserver erst wieder auf RAID umgestellt habe - ich habe ein paar Kunden dabei, die das wirklich beobachten.

flo.

Hab es nun seit 1 Tag im produktiven Betrieb laufen, bisher ist mir nichts aufgefallen. Also geh ich nun mal davon aus dass es für einen Webserver kein Problem darstellt

EDIT: Scheiße, wegen meinem Testfile für den Exploit (ca. 1GB groß) ist mein Backup Space geplatzt. Ich hab nur 2GB und sicher nur das nötigste... 4 Tage kein Backup, tödlich... :( Noch tödlicher aber wahrscheinlich, dass ich es nicht vorher bemerkt habe...
Direkt mal die Dateien löschen und das Script manuell starten...

PS: Ich weiß, dass mein Edit völlig OT ist, aber ich musste meinen Frust mal rauslassen.

[flo]

EDIT: *piep*e, wegen meinem Testfile für den Exploit (ca. 1GB groß) ...

Das war unnötig - das tar.gz des 2.6er Kernels reichte vollkommen aus ... :-(

flo.

[standbye]

Spender hat einen grsecurity patch für den aktuellen kernel ;)

http://www.grsecurity.net/~spender/grse ... 1226.patch

[thorsten]

Weiter unten im Thread wurde gesagt, dass man mit grub keinen kernel für den nächsten boot auswählen kann.
Dem ist aber nicht so!
Bei debian ist das 38 zeilige shellscript grub-reboot dabei, mit dem man den kernel für den nächsten Neustart auswählen kann.

Da ich auch keine rescue-console bei meinem Server habe, installiere ich den neu gebackenen kernel herkömmlich über dpkg -i $KERNEL.deb, rufe update-grub auf, schaue in die Datei /boot/grub/menu.lst und setze den Punkt default von 0 auf 2.
=> Der 3. kernel-Eintrag ist nämlich nach einer neuen Kernelinstallation der derzeit laufende.
Nun rufe ich grub-reboot auf, wähle den kernel 0 aus und sage reboot.
Kommt die Maschine hoch, ist alles in Butter und ich setze in der /boot/grub/menu.lst den Wert default auf 0.

Wenn die Maschine nicht hochkommt, maile ich den fleißigen Chris an, der für einen reboot sorgt und die Kiste fährt mit dem älteren kernel hoch und baue wieder einen kernel ;)

Wer kein debian hat, kann sich das Script aus dem Paket grub hier herunterladen: http://packages.debian.org/stable/admin/grub
Oder den Eintrag selbst in der grub-shell setzen:

Code: Select all

# grub
grub> savedefault --once --default=0
grub> quit

[blnsnoopy26]

Spender hat einen grsecurity patch für den aktuellen kernel ;)

http://www.grsecurity.net/~spender/grse ... 1226.patch

Ich bin mal so frei und berichtige die url :D

http://www.grsecurity.net/~spender/grse ... 1736.patch

bei deinem link kommt 404 not found :D

[blnsnoopy26]

Funktioniert es auch mit Suse dein mini howto?
Weil ich habe ja wie gesagt keine Remote Konsole.

Reicht es, wenn ich den neuen Kernel in meine menu.lst eintrage oder wie läuft das da genau ab?

Wer kein debian hat, kann sich das Script aus dem Paket grub hier herunterladen: http://packages.debian.org/stable/admin/grub

Die Seite ist nur für Debian und ich habe SuSE

[thorsten]

du brauchst das Script nicht, wenn du die grub-shell über grub aufrust - das Script nimmt dir die 'Arbeit' nur ab.

Wie du unter deiner SuSE einen kernel installierst, kann ich dir nicht sagen. Als ich zuletzt SuSE benutzte, gab es nur lilo ;)

Das Prinzip ist aber natürlich das selbe und du kannst es ja in einem vmware-image ausprobieren - dafür ist der vmware-player doch da :)

Die o.g. Seite ist für debian und du kannst das grub-debian Paket einfach herunterladen und mittels ar auspacken. Dann findest du auch in einem bin Verzeichnis das Script grub-reboot

Ansonsten:
Steig um auf debian oder Ubuntu - das Netz ist voll guter Anleitungen für diese Distributionen :twisted:

[blnsnoopy26]

Wie ich unter SuSe ein Kernel baue und installiere das weiss ich - hab mich da nicht deutlich ausgedrückt.

Es ging jetzt nur darum wegen dem Notfall, falls der Server nicht mehr bootet.

so sieht meine menu.lst aus:

Code: Select all

###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE LINUX 9.3
    kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 vga=0x31a selinux=0  splash=silent resume=/dev/hda5  showopts
    initrd (hd0,0)/boot/initrd

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- SUSE LINUX 9.3
    kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 showopts ide=nodma apm=off acpi=off vga=normal noresume selinux=0 barrier=off nosmp noapic maxcpus=0  3
    initrd (hd0,0)/boot/initrd

müsste ich quasi dann dort mein grsec kernel eintragen und als default ein anderen setzen? Weil habe das jetzt nicht richtig verstanden.

[thorsten]

in der menu-lst steht irgendwo default 0
Damit bootet grub den 1. Kernel - und der fängt bei dir mit title SUSE Linux 9.3 an.
Der nächste (würde default 1 sein) ist der failsafe Eintrag.

Installierst du einen neuen kernel, so steht er bei debian ganz als 1. in der menu.lst und der aktuell noch laufende rutscht von Platz 1 (default 0) auf den 3. Platz (default 2).
Ich hoffe das klärt deine Frage...

[blnsnoopy26]

in der menu-lst steht irgendwo default 0
Damit bootet grub den 1. Kernel - und der fängt bei dir mit title SUSE Linux 9.3 an.
Der nächste (würde default 1 sein) ist der failsafe Eintrag.

Installierst du einen neuen kernel, so steht er bei debian ganz als 1. in der menu.lst und der aktuell noch laufende rutscht von Platz 1 (default 0) auf den 3. Platz (default 2).
Ich hoffe das klärt deine Frage...

Also kann man sagen ist es vergleichsweise wie mit der windows XP boot.ini, wo man sagen kann was default ist und was nach ablauf des Timers dann gebootet wird?

Wenn dem so ist dann ist es anhand meiner menulist so, das was ganz oben steht zuerst geladen wird.

Nur wie bringt man grub es bei bei einem erneuten reset den nächstliegenden Kernel zu booten?! Das war jetzt die Preisfrage

Natürlich könnte ich einen weiteren titel einbauen mit dem funktionierenden Kernel und wenn ich meinem anbieter dann sage das er dann in der menuwahl nur den Alternativkernel wählen muss, dann wäre es vergleichsweise wie mit windows boot.ini wo man am anfang sein Betriebssystem wählt.

[blnsnoopy26]

Hi,

Irgendwie funzt der Patch nicht, wenn ich anfange mit "make" zu kompilieren kommt immer nur:

Code: Select all

In file included from arch/i386/kernel/ldt.c:21:
include/asm/mmu_context.h: In function `switch_mm':
include/asm/mmu_context.h:55: error: structure has no member named `user_cs_base'
include/asm/mmu_context.h:55: error: structure has no member named `user_cs_base'
include/asm/mmu_context.h:56: error: structure has no member named `user_cs_limit'
include/asm/mmu_context.h:56: error: structure has no member named `user_cs_limit'
make[1]: *** [arch/i386/kernel/ldt.o] Fehler 1
make: *** [arch/i386/kernel] Fehler 2

ohne grsec Patch läuft es ohne probleme durch.
Patchen tue ich so:

Code: Select all

patch -p1 < grsecurity-2.1.9-2.6.17.6-200607241736.patch

Der Patch läuft auch ohne Fehlermeldung durch, aber nach dem ausführen von "make" kommt der Kompilierungsvorgang nicht weit :?

edit:

Sobald ich im Kernel die grsec Option aktiviere, ist ein Kompilieren nicht mehr möglich, mit der besagten Fehlermeldung.

Hatte noch nie Probs mit den Patches von grsec aber diesmal scheint es anders zu sein :?

[elch_mg]

Welche Kernelsourcen hast du damit gepatcht?

[wgot]

Hallo,

Also kann man sagen ist es vergleichsweise wie mit der windows XP boot.ini, wo man sagen kann was default ist und was nach ablauf des Timers dann gebootet wird?

Das kann Grub auch, nützt aber natürlich beim Server nix weil man (ohne Konsole) keine Taste drücken kann.

Die Lösung funktioniert anders: beim nächsten Neustart bootet grub einmalig den neuen Kernel und bei allen weiteren Reboots wieder den alten ganz unabhängig davon ob der neue funktioniert. Wenn der neue nicht startet genügt somit ein Reset um wieder den alten kernel zu laden.

Das Script ist auch bei Suse dabei, nennt sich dort grubonce. Als Parameter wird eine Zahl erwartet die angibt der wievielte Eintrag (ab 0 gezählt) von menu.lst beim nächsten Boot einmalig gestartet werden soll.

Nur wie bringt man grub es bei bei einem erneuten reset den nächstliegenden Kernel zu booten?

Grub bootet immer den hinter default angegebenen Eintrag, aber einmalig den bei grubonce angegebenen, damit erfolgt das Zurückschalten auf den alten Kernel durch einen einfachen Reset.

Es gibt auch eine kompliziertere Konfiguration bei welcher Grub erst den neuen Kernel bootet und automatisch ohne Reset danach den alten sofern der neue nicht startet:

http://www.gnu.org/software/grub/manual ... ck-systems (4.3.2)

Gruß, Wolfgang

[blnsnoopy26]

Welche Kernelsourcen hast du damit gepatcht?

Habe mir die sourcen 2.6.17.6 frisch von http://www.kernel.org besorgt gehabt. Patch und Kernelversion passen als daher zusammen, daher verstehe ich das nicht.

Sobald ich die Option grsecurity im Kernel aktiviere kommt diese schöne Fehlermeldung. Dachte zuerst liegt an meiner .config, aber dann habe ich meine default .config genommen und dann einmal, wo ich schon einmal grsec mit kompiliert habe, aber alles Fehlanzeige.

Es ist ist nicht der erste grsec Kernel den ich baue und meine Vorgehnsweise ist auch immer gleich. Ich denke mal das am patch was nicht stimmt, weil ohne Patch wird der Kernel ja gebaut.

[elch_mg]

hm... auch ordentlich make clean etc. vorher gemacht?
Ich hab den .17.6 mit den grsec-.17.4 gepatcht, das hat reibungslos funktioniert. Mal sehn, ob das bei mir auch auftritt wenn ich den neuesten Patch nehme.

[blnsnoopy26]

Hi,

Hier mein Vorgang:

Code: Select all

- wget kernel_source.tar.gz
- tar xzf kernel_source.tar.gz
- cd kernel_source_verzeichnis
- make mrproper
- wget grsecurity-2.1.9-2.6.17.6-200607241736.patch
- patch -p1 < grsecurity-2.1.9-2.6.17.6-200607241736.patch
- cp /boot/config /usr/src/kernel_verzeichnis/.config
- make menuconfig
- Laden meiner .config File
- Meine einstellungen tätigen
- exit -> Save config
- make

Diesen vorgang kann ich schon im schlaf und verstehe es deshalb nicht. Es gab seit dem ich grsec nutze noch nie Probs mit den Patches.

[elch_mg]

wo ist dein make oldconfig?

[captaincrunch]

Nicht da. Wozu auch?

[thorsten]

Mir fehlte der oldconfig-Aufruf auch, bis ich drauf gekommen bin, dass er exakt die kernelversion schon laufen hat und nun diese kernelversion mit grsec zu übersetzen versucht.
(Auf der anderen Seite schadet es nicht make oldconfig aufzurufen)

Ich hatte bei früheren 2.4er kernel öfter mal das Problem, dass sich der kernel partout nicht übersetzen lies. ein make mrproper hats dann gerichtet. Wenn man also feststeckt, sollte man die .config sichern und den Saubermann drüber laufen lassen.

[elch_mg]

Ich hatte bisher immer im Hinterkopf, dass ein make oldconfig (nahezu) zwingend erforderlich ist - Es hat bei mir auch durchaus mal für Erfolg gesorgt.
Aber wenn dem nicht so ist, okay ;)

make mrproper o.ä. ist aber Pflicht wie ich meine. Es scheint wohl sonst zu so Fällen kommen wie, dass ein zuvor als Modul kompiliertes Feature dann statisch im Kernel liegt und als Modul vorhanden ist.. Wie genau das jetzt für Fehler sorgt weiss ich nicht, aber es hakt dann an den dollsten Dingern. Jedenfalls bei mir (:

[blnsnoopy26]

Hi,

Um alle fehler auszumärzen habe ich auch mal vorher vor dem patchen make oldconfig gemacht, weil in der .config war ja noch kein grsec mit drinnen.

Danach habe ich den Patch eingesetzt habe dann make menuconfig aufgerufen und grsec aktiviert und meine Einstellungen vorgenommen, aber beim make kam er dann wieder nicht sehr weit.

Code: Select all

linux:/usr/src/linux-2.6.17.6 # make
  CHK     include/linux/version.h
  UPD     include/linux/version.h
  SYMLINK include/asm -> include/asm-i386
  SPLIT   include/linux/autoconf.h -> include/config/*
  CC      arch/i386/kernel/asm-offsets.s
  GEN     include/asm-i386/asm-offsets.h
  HOSTCC  scripts/genksyms/genksyms.o
  SHIPPED scripts/genksyms/lex.c
  SHIPPED scripts/genksyms/parse.h
  SHIPPED scripts/genksyms/keywords.c
  HOSTCC  scripts/genksyms/lex.o
  SHIPPED scripts/genksyms/parse.c
  HOSTCC  scripts/genksyms/parse.o
  HOSTLD  scripts/genksyms/genksyms
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
  HOSTCC  scripts/mod/modpost.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/bin2c
  CC      init/main.o
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  CC      init/do_mounts.o
  CC      init/do_mounts_rd.o
  CC      init/do_mounts_initrd.o
  CC      init/do_mounts_md.o
  LD      init/mounts.o
  CC      init/initramfs.o
  CC      init/calibrate.o
  LD      init/built-in.o
  HOSTCC  usr/gen_init_cpio
  GEN     usr/initramfs_data.cpio.gz
  AS      usr/initramfs_data.o
  LD      usr/built-in.o
  CC      arch/i386/kernel/process.o
  CC      arch/i386/kernel/semaphore.o
  CC      arch/i386/kernel/signal.o
  AS      arch/i386/kernel/entry.o
  CC      arch/i386/kernel/traps.o
  CC      arch/i386/kernel/irq.o
  CC      arch/i386/kernel/ptrace.o
  CC      arch/i386/kernel/time.o
  CC      arch/i386/kernel/ioport.o
  CC      arch/i386/kernel/ldt.o
In file included from arch/i386/kernel/ldt.c:21:
include/asm/mmu_context.h: In function `switch_mm':
include/asm/mmu_context.h:55: error: structure has no member named `user_cs_base'
include/asm/mmu_context.h:55: error: structure has no member named `user_cs_base'
include/asm/mmu_context.h:56: error: structure has no member named `user_cs_limit'
include/asm/mmu_context.h:56: error: structure has no member named `user_cs_limit'
make[1]: *** [arch/i386/kernel/ldt.o] Fehler 1
make: *** [arch/i386/kernel] Fehler 2

Also an mir soll das ganze nicht liegen. Glaube eher es liegt am Patch selber.

[blnsnoopy26]

Hi,

Bin doch nicht alleine mit meinem Fehler.
Im forum von grsec wird das auch besprochen wo jemand den Fehler hat:

--> http://forums.grsecurity.net/viewtopic.php?t=1516

Also liegt es tatsache an dem Patch und hängt wohl mit dem PAX zusammen, wenn ich das im grsec forum richtig gelesen habe.

Dachte schon jetzt stelle ich mich zu doof an, um nen Kernel zu patchen oder ähnliches :-D :lol:

[elch_mg]

Von wegen es treten keine Fehler auf.. Ich wunder mich, warum ich seit Tagen keine Syslog-Einträge mehr bekomm und Mails nicht oder verzögert ankommen - Namensauflösung will nicht mehr, und grsec schuld. ARGH!

Ich kompilier grad .17.6 mit dem dazugehörigen grsec-patch, mal sehn was passiert...