neuer Kernel-"Crash-Exploit"

[crasline]

ja ne, nur das mit dem patch wollt ich wissen .. die kernel config hab ich mir eh schon lang unten den Nagel gerissen :)

[pf4]

Kernel läuft, Testexploid ohne erfolg.
big THX

[KriS]

Hi,

updated, reboot, test -> für sehr gut befunden -> Happy!

Danke

So long
KriS

[ffl]

Auch hier nach 2 Reboots (hatte beim 1. Mal vergessen den symlink zu ändern) all systems up and running!

Dickes Dankeschön!

[Outlaw]

http://linux.roothell.org/kernel/

-> kernel-image-2.4.26-grsec-ipv6_2_i386.deb
-> kernel-image-2.4.26-grsec_2_i386.deb

Bitte um kurze Rückmeldung

Was für Voraussetzungen muss man mitbringen, um diese Kernel einzusetzen ??

Oder kann die "jeder" draufmachen und gut ??

Gruß Outi

[captaincrunch]

Was für Voraussetzungen muss man mitbringen, um diese Kernel einzusetzen ??

In dem Fall ist Debian die Grundvorasussetzung. ;)

[helling3r]

der 2.6.7er Kernel wurde released, er behebt das problem ebenfalls.

[mitmacher]

mannomann, iss ja schon wieder ein ding... :-(

aber sagt mal:
Wo gibts denn mal einen gepatchten 1und1-SuSE9.0-Kernel 2.4.26???
Oder was kann ich mehr tun als auf ein 1und1-Update zu warten?

Die empfehlen ein selber-patchen... hm... schön + gut, aber was haben die denn alles aktiviert? Wie wird welches Netzwerk-Modul eingebunden, etc.?

Wenn man Zeit hätte, liesse sich das sicher alleine regeln, aber bitte nicht auf Produktiv-Servern im laufenden Betrieb! :evil:

tja, blöde Sache! Stellt sich wieder die Frage, warum kein Standard-Kernel zum Einsatz kommt, der über YaST updatebar wäre, aber natürlich ist mir klar, dass dies sehr naiv gedacht ist. Nur: was tun?

Ohne Ahnung von Linux soll/darf man keinen Rooty mieten, schon klar, aber muss man nun auch gleich unter die Kernel-Profis gehen, nur weil da EIN Bug auftaucht? Ich hoffe nicht, denn das ist schon eine Klasse für sich IMHO (nehmt's als Kompliment *g*).

[sascha]

Die empfehlen ein selber-patchen... hm... schön + gut, aber was haben die denn alles aktiviert? Wie wird welches Netzwerk-Modul eingebunden, etc.?

Config ist bei den 1&1 Kernels dabei... sollte also kein Problem darstellen

tja, blöde Sache! Stellt sich wieder die Frage, warum kein Standard-Kernel zum Einsatz kommt, der über YaST updatebar wäre, aber natürlich ist mir klar, dass dies sehr naiv gedacht ist. Nur: was tun?

Weil der Standard-Kernel nicht so toll ist ;). Also entweder patchen oder noch etwas warten bis 2.4.27 kommt. Ich denke mal dass 1&1 den auch wieder bereitstellen wird.

[mitmacher]

manno, einfach warten ist auch nicht so toll :twisted:

Config ist bei den 1&1 Kernels dabei... sollte also kein Problem darstellen

Ok, das sieht tatsächlich schonmal gut aus, aber wie genau wird das Config-File genutzt? Sorry, aber irgendwann ist immer das erste Mal... :oops:

Und dann das Netzwerk. Mir wurde telefonisch mitgeteilt, man müsste da ein bestimmtes Modul einbinden, aber wo, wie + welches?
Im Kernel-Config stehen doch bereits folgende Einträge:

Code: Select all

CONFIG_NET_PCI=y
CONFIG_AMD8111_ETH=y
CONFIG_E100=y
CONFIG_8139TOO=y
CONFIG_VIA_RHINE=y

CONFIG_E1000=y
CONFIG_TIGON3=y

Und "lspci" sagt mir:

Code: Select all

00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)

Also wird doch nix weiter als die kernel-Quellen, die Config und der Anti-Crash-Patch benötigt, um das Kompilat zu erstellen?

Wenn es denn laut vieler Meinungen alles soooo einfach ist, dann schreibt doch mal bitte knapp und präzise nieder, wie man es auf einem 1&1-Server (2.4.26) am einfachsten bewerkstelligt *bettel*

Ich habe wirklich keine Lust auf fehlgeschlagene Experimente!!!

[captaincrunch]

Schau dir einfach mal meine Configs an, die sind schon relativ abgespeckt, und dürften als gute Basis dienen: http://linux.roothell.org/kernel/

[mitmacher]

hm, danke noch mal für den Rat aber wie gesagt, interessiert mich eher SuSE 8O

und beim überfliegen deiner config fiel mir z.b. auf:
- kein scsi (als dummy nicht notwendig?)
- noch mehr Network-Driver, aber Via=m?
- viele andere unterschiede...

Wie soll man da durchblicken, was nötig ist und was nicht? Ich bin überzeugt, einer Menge Leute allmählich eine ganze Menge über Linux oder Programmierung erzählen zu können *selbstbeweihräucher* aber das hier ist mir leider etwas zu hoch... :-(

Dabei ist es doch so fundamental wichtig... Ich würde demjenigen, der mir eine taugliche Anleitung liefern täte prompt ein Eis ausgeben (Postweg *g*)! habe aber natürlich wenig hoffnung nach meiner DAU-Offenbarung in diesem Bereich... :(

*teatime*

[captaincrunch]

hm, danke noch mal für den Rat aber wie gesagt, interessiert mich eher SuSE

Kernel bleibt Kernel, egal, wer da was dran rumgepfuscht hat.

- kein scsi (als dummy nicht notwendig?)

Nö, wozu?

- noch mehr Network-Driver, aber Via=m?

Ja, wozu auch ein Netzwerkmodul fest einkompilieren?

Die o.g. Config läuft auf diversen Kisten seit geraumer Zeit problemlos, und ehrlich gesagt kann ich mir nicht vorstellen, warum es bei deiner anders sein sollte. ;)

[mitmacher]

oki, langsam komme ich dahinter... :roll:

aber eine Sache machte mich mal gerade stutzig:
Ich hab halt den 1&1-2.4.26-040421-Kernel drauf und in /boot liegt auch das passende config-File.
wenn ich nun mit diesem testhalber OHNE Ã?nderungen die 2.4.26-Src kompiliere (auf demselben Server), würde ich erwarten, dass das Resultat identisch ist. Aber:

Code: Select all

-rw-r--r--    1 root     root      1150303 Apr 21 13:49 vmlinuz-2.4.26-040421
-rw-r--r--    1 root     root      1249801 Jun 19 00:19 vmlinuz-2.4.26-040422p

und:

Code: Select all

-rw-r--r--    1 root     root       559882 Apr 21 13:49 System.map-2.4.26-040421
-rw-r--r--    1 root     root       561797 Jun 19 00:19 System.map-2.4.26-040422p

(das "p" sollte ursprünglich patched heissen, stimmt aber [noch] nicht)

Also, wieso unterscheiden die sich schon, ohne, dass ich da was dran gedreht habe??? Ich trau mich das einfach nicht zu booten... :-(

[sascha]

Ich vermute das liegt daran, dass 1&1 die Kernel auf einem Debian System backt, und somit andere Softwareversionen verwendet (gcc, glibc...) als du auf deinem SuSE System.

[captaincrunch]

So ist es. Wa sagt auf der Kiste z.B. ein gcc -v ?

[yt]

Code: Select all

# gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.2

Sollte bei ihm ähnlich aussehen (SuSE 8.1, 1&1)

[captaincrunch]

Tja, und da Debian auf den guten alten gcc-2.95 setzt, haben wir den o.g. Unterschied. ;)

[yt]

Erstaunlich - ich hätte nicht gedacht, dass der Unterschied so groß ist.

[captaincrunch]

Der Unterschied kann alleine schon durch unterschiedliche Compilerflags mit der gleichen gcc-Version hervorgerufen werden.

[mitmacher]

Code: Select all

gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.1/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --disable-checking --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.1 (SuSE Linux)

ok, macht Sinn, das mit den verschiedenen gcc-Versionen, bzw. Debian, etc. Also werde ich dann heute nacht mal den Versuch wagen :-)
Ansonsten sah ja alles fehlerfrei aus, soweit man das beurteilen kann. Nach genauerem Vergleichen der Configs (1&1/Roothell) denke ich nun auch, dass die Roothell-Variante evtl. doch besser sein könnte (lieber später als nie *g*). Thx CC again...

hm, und wenn ich roothell erst lokal testen will? muss da ausser der CPU und dem Netzwerk noch viel weiteres angepasst werden? Eigentlich doofe Frage, ich weiss, aber der Rest wirkt auf mich halt recht allgemein gehalten, so dass bereits viele HW-Komponenten integriert sein dürften.

Aber wahrscheinlich ist es eher normal + sinnvoll, sich bei jedem neuen/anderen System erstmal von hand durch die Optionen wurschteln zu müssen... 8O

[Joe User]

Der Unterschied kann alleine schon durch unterschiedliche Compilerflags mit der gleichen gcc-Version hervorgerufen werden.

Was in diesem Fall (Kernel) ein Pfuschen im Makefile voraussetzt...

[captaincrunch]

In dem Fall war es auch eigentlich eher allgemein gedacht, aber ich für meinen Teil schrecke auch vor einer Vergwohltätigung des Makefiles ncht zurück. ;)

[Joe User]

In dem Fall war es auch eigentlich eher allgemein gedacht, aber ich für meinen Teil schrecke auch vor einer Vergwohltätigung des Makefiles ncht zurück. ;)

Aber auch nur, wenn Du weisst, was Du Deinem Kernel dadurch antust ;) Otto Normal weiss dies im Allgemeinen nicht und soll daher auch die Griffel von derartigen Modifikationen, nicht nur beim Kernel, lassen.

[pickel]

hi,

mal ne blöde frage, was soll nach dem kernelupdate passieren (hab den exploit vorher net getestet). wenn ich es jetzt (nach patchen) aufruf malt er viele punkte und abundzu paar * zwischendurch...

Ist das ok oder eher nicht?

mfg,
nils

EDIT: achja, das programm lässt sich via strg + c einfach killen, vondaher denke ich mal, dass es in ordnung ist, möchte nur gern eine bestätigung haben :D