|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
| |
 |
|
|
|
|
|
|
|
Morton ist aber derjenige, der den Bug initial entdeckt hat. Und er hat ihn auch nicht bekannt gegeben...
Nunja, die Entscheidung bzgl. 2.4.23 kann wohl nur bei Tossati gelegen haben, ja...
Und ich werde so das dumme Gefühl nicht los, wenn die Debianer nicht den Bug durch ihre forensischen Untersuchungen aufgedeckt hätten, würden wir auch heute noch nix davon wissen.
--
There is no place like $HOME
|
|
|
|
|
|
|
|
|
|
|
|
|
Ist ja schon gut, wenn sich alle zuerst mal über die ach so unverantwortlichen Kernel Maintainer aufregen, die nicht an die User denken...
Laut einer Diskussion auf debian-devel [1] ist das ganze aber nicht ganz so einfach. Andrew Morton und auch alle Distributoren gingen davon aus, das es sich nur um einen normalen Bug und nicht um einen möglichen root Exploit handelte. Erst die Analyse nach dem Debian crack zeigte, dass sich dieser Bug für einen Root Exploit eignete.
[1] http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg00187.html
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 02. December, 16:22 MET (#15)
|
|
|
|
|
du hättest von mir ein "-1, Troll" verdient, denn du machst hier nichts anderes, als andere an den Pranger zu stellen ohne selbst etwas Produktives zu leisten.
Bei Linux sind es nicht "die da oben", denen man die Schuld geben kann. Auch du hättest schon lange ein Mail an die LKML schicken können und mit Nachdruck auf diesen lokalen Root-Exploit hinweisen können, statt im Nachhinein anderen Untätigkeit vorzuwerfen.
Es wurde von der ganzen Community schlicht nicht erkannt, wie gravierend dieser Bug ist (dass er eben als Root Exploit dienen kann). Das Mehraugenprinzip (wie in der Open Source Entwicklung) ist das beste Mittel gegen solche Fehler, eine Garantie kann es aber auch nicht liefern.
Das nächste Mal bitte selbst Hirn einschalten, bevor du wie ein N00b über andere herziehst. Denk an die Hacker-Ethik.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 02. December, 07:01 MET (#2)
|
|
|
|
|
"but unfortunately that was too late for
the 2.4.22 kernel release"
Diese Entscheidung verstehe ich jetzt wirklich nicht. Wenn es ein solches Loch gibt dann sollte man doch verd@*ç& nochmal gleich 2.4.23 nachlegen, sowas kann doch echt nicht sein!
Wer weis was sonst noch für Systeme durch den Bug betroffen sind.
|
|
|
|
|
|
|
|
|
|
|
|
|
Wieso kann man nicht einfach, security patches veröfentlichen 2.4.22p2 oder sowas? Und immer wenn ein neuer Kernel herauskommt weiss man welche Bug der alte hatte, war schon bei 2.4.21 so. Schade, man weiss ja eingentlich das das verstecken vor allem bei OpenSource Software nicht funktioniert.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das wird ja von den meisten Distributionen auch gemacht. Gepatchte Kernels rausbringen, mein ich.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ist mir mir ziemlich peinlich - aber da ich meinen remote-admin Server nicht zerschiessen will: Wie wird das Update installiert? apt-get update und apt-get dist-upgrade machen gar nichts (ja, security.debian.org steht in der sources.list).
Können Kernel-Updates überhaupt via apt-get installiert werden, oder muss das händisch erledigt werden?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, wenn das Orginal Debian Kernel Image installiert ist. Das Package heisst sowas wie kernel-image-2.4.18-1-386.
Nein, wenn man einen eigenen Kernel gebacken hat. Dann sollte man den neusten Kernel von www.kernel.org herunterladen, mit z.b. mit make menuconfig konfigurieren und danach mit make-kpkg --revision=1.0 kernel_image kompilieren. Das Tool generiert automatisch ein Debian Packgage, welches danach einfach mit dpkg installiert werden kann.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Vorsicht!
Ich habe vor ein paar Monaten auch zum
ersten Mal auf meiner Debian-Kiste einen
Kernel direkt von kernel.org runtergeladen
und mit make-kpkg (Ein geniales Tool, so
nebenbei) gebacken.
Funktioniert alles prima, solange man keine
initrd verwendet. make-kpkg erzeugt
nämlich initrd's,
die von einem kernel.org - Kernel nicht
gelesen werden können. Da braucht es einen speziellen Debian-Patch, den ich leider
bis jetzt nirgends
'standalone' gefunden habe.
Abhilfe: Kein initrd verwenden oder warten,
bis der neue Kernel gepatcht als
kernel-source...deb in unstable
erscheint. Das .deb kann auch auf einem
woody-System mit dpkg -i installiert
werden, ohne gleich auf testing/unstable
ugraden zu müssen.
Es gibt auch noch die
Möglichkeit, mkinitrd.conf so anzupassen,
dass kein cramfs sondern ein anderes
Format für die initrd verwendet wird.
Das habe ich allerdings nicht getestet.
AFAIK müsste ein 'plain vanilla' kernel
diverse andere komprimierte Formate
lesen können.
|
|
|
|
|
|
|
|
| |
|
|
|
|
Von Anonymer Feigling am Tuesday 02. December, 14:38 MET (#12)
|
|
|
|
|
Gibt es einen einzelen kleinen Patch denn ich am entsprechender Stelle meiner Kernel-Sources einfuegen kann?
Dann kann ich alles beim alten lassen, nur diesen Bug fixen und neu kompilieren.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 02. December, 16:11 MET (#14)
|
|
|
|
|
Das würde ich nicht machen, denn vermutlich hat dein alter Kernel auch sonst noch ein paar Sachen, die in der aktuellsten Version besser gelöst sind.
1.) neuen Kernel runterladen und in /usr/src entpacken
2.) cd /usr/src/neuerkernel
3.) make mrproper
4.) cp ../alterkernel/.config .
5.) make oldconfig
danach wie üblich den Kernel inklusive Module neu kompilieren und installieren:
6.) make dep bzImage modules modules_install
(dep ist ab 2.6.x nicht mehr nötig)
7.) cp arch/i386/boot/bzImage /boot/bzImage-neuerkernel
(bzw. statt i386 deine architektur angeben)
und bei grub das menu aktualisieren oder mit lilo den neuen Kernel eintragen
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 02. December, 18:09 MET (#16)
|
|
|
|
|
BTW du kannst statt des ganzen neuen Kernels natürlich auch nur den Patch von der Vorversion zur aktuellen Version runterladen (spart Zeit und Bandbreite). Den musst du dann aber noch anwenden.
|
|
|
|
|
|
|
