Der nächste Kernel-Bug

[captaincrunch]

Paul Starzetz hat den nächsten Bug im Kernel gefunden:
http://isec.pl/vulnerabilities/isec-0015-msfilter.txt

Betroffen sind die Versionen 2.4.22 - 2.4.25, 2.6.1 - 2.6.3. Obwohl der Bug (anscheinend) nicht remote ausgenutzt werden kann, kann er lokalen Usern root-Privilegien verschaffen. Ein Update wäre also angebracht. Neue Debianhowto-Kernel wird's in Kürze geben.

[phantom]

8) Komm' schon CC, wir warten jetzt seit über einer Stunde. 8)

[pf4]

Keine Panik !

Die paar min machen die Kuh nimmer fett

[Joe User]

Selber backen ;)

[pf4]

meiner Backt (okok mit CC's config)

hoffendlich wird das was

[dodolin]

Hi-hi, witzig: Diesmal bin ich mit meinem abgehangenen 2.4.18 Woody-Standard-Kernel gar nicht betroffen... :)

[oxygen]

Also wenn ich das richtig sehe, sollte der Exploit auch nur mit aktiviertem Multicast funktionieren, es wäre nämlich höchst unlogisch wenn jene Funktion auch ohne Multicastfunktionalität zur Verfügung steht.

[pf4]

Testen würde ich sagen ;)


Was ist eigendlich mit grsec los, bei den letzen paar Lücken war es vollkommen wirkungslos ;)

[captaincrunch]

Auch GRSecurity ist halt kein Allheilmittel, erst recht nicht gegen unsaubere Programmierung. :?

Die Sache mit dem fehlenden Multicast-Support beim DH-Kernel ist mir auch erst im Laufe des Abends eingefallen, als ich noch im Auto saß, genau das wird gerade mal gecheckt.

[ffl]

Vorschlag: bau doch bitte das FTPFS-Modul gleich mit, da es sinnvoll für die FTP-Backup-Funktion eines großen deutschen Rootserveranbieters ist.

Danke ;-)

[captaincrunch]

Dann schon eher lufs, das kann noch viel mehr...wobei es da ohnehin ein eigenes Paket gibt, das ich irgendwann mal gebackported habe.

[captaincrunch]

So, hier also ganz konservativ ohne bislang (von mir) nicht getesteten Code:
http://linux.roothell.org/kernel/

Dafür ist nun aber GRSecurity in Vesion 2.0, das e1000-Modul und ReiserFS wie gehabt als Modul drin; die sonstigen Kleinigkeiten können dem kernel-config-File entnommen werden. Feedback bitte nicht in diesem Thread...grundsätzlich aber natürlich gerne. ;)

[mikespi]

Hallo,

wie schlimm ist ein Rootserver von diesen Lecks eigentlich betroffen?

Irgendwie verstehe ich nicht ganz wie die Lücke genutzt werden kann, kann mir jemand das etwas näher bringen .

Vielen Dank

Grüsse
Andi


@CC Danke für den vorgebackenen Kernel, aber ich denke du solltest da nicht immer so viel Vorarbeit machen, sonst lernen wir das nie 100%ig. ;)

[ffl]

Okay, wie komm ich an dein LUFS-Paket? Kann ich dann damit so wie mit FTPFS den FTP mounten?

Edit: könntest du bitte noch deine gepatchten Sourcen als tar.gz oder so zur Verfügung stellen? Hab grad arge Probs mit dem grsec 2.0!

FTPfs läuft wieder, allerdings nur in der ip4-Version, mit der anderen hats nicht geklappt (Müdigkeit!). Also, das mit den Sourcen wär echt nett...

Gruß
ff

[phantom]

Danke, CC! Funktioniert nach ersten Tests prima. :)

[captaincrunch]

wie schlimm ist ein Rootserver von diesen Lecks eigentlich betroffen?

Sofern du lokale User auf der Kiste hast, könnten diese die Lücke ausnutzen. Ob sie es auch bei DH-Kerneln aufgrund des fehlenden Multicast-Supports auch könnten (wobei es eigentlich eher um den SysCall geht), konnte ich gestern Abend leider nicht mehr in Erfahrung bringen. Ich werde das heut aber weiter diskutieren. Da die Gefahr allerdings besteht, gab's halt neue Kernel.
Sobald ich dazu mehr weiß, wird's hier bekannt gegeben.

Danke für den vorgebackenen Kernel, aber ich denke du solltest da nicht immer so viel Vorarbeit machen, sonst lernen wir das nie 100%ig.

Daher gibt's auch bestimmt irgendwann mal das lange angekündigte Kernel-Howto. ;)

Okay, wie komm ich an dein LUFS-Paket?

Such ich gleich raus.

Kann ich dann damit so wie mit FTPFS den FTP mounten?

Ja.

Edit: könntest du bitte noch deine gepatchten Sourcen als tar.gz oder so zur Verfügung stellen? Hab grad arge Probs mit dem grsec 2.0!

Könnte ich tun, wüsste aber gerade ehrlich gesagt nicht, was das bringen sollte (mal ganz davon abgesehen, dass das ein verdammt großer Tarball wäre). ;)
Was für Probleme hast du denn damit?

Danke, CC! Funktioniert nach ersten Tests prima.

I know. ;)

[captaincrunch]

Update: sobald IPv4-Support im Kernel aktiviert ist, ist der betreffende Code aktiv, ergo "schützt" einen fehlender Multicast-Support nicht wirklich. Remote ist diese Lücke aber (bislang) nicht ausnutzbar.

[tic]

Ne Frage zu dem neuen Kernel von CapCrunch mit grsec2.

Hat sich da gegenüber den vorherigen kernels was mit den acl's geändert?
Ich hab den (peinlich) einfach so im guten Glauben eingebaut und nach dem Reboot gleich den Verdacht gehabt dass ich da ein Schreibproblem mit den Capabilities hab das bei vorherigen CrunchKerneln nicht da war und hab das Ding sicherheitshalber gleich mal in den Rescuemodus gefahren und den alten Kernel wieder aktiviert.

Ich hab freilich auch ein fsck über alle partitionen gemacht und die /var Partition war auch tatsächlich ziemlich zerschossen. Ext3 sei Dank passt alles flott und perfekt wieder.

Bin ich der einzige mit diesem Erfahrungsbericht?
Ich meine, irgendwie braucht es aktuell zuviele (Sicherheits)Updates als dass ich ein lids ähnliche restriktive Umgebung möchte.

Ich hab auch kein gradm installiert.

gruß
Manfred

[tic]

Hoppla,

jetzt mach er remount-ro on error seh ich.
Ich glaub jetzt wird's offtopic

[captaincrunch]

TPE und ACLs sind in den Images deaktiviert.

[tic]

dann ist /dev/hda8 im A****

fsck -f /dev/hda8
Error reading block 1559 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error<y>?

[ffl]

Okay, wie komm ich an dein LUFS-Paket?

Such ich gleich raus.

Wo ist es :) ?
Edit: Ist es das: http://linux.roothell.org/lufs/ ?

Edit: könntest du bitte noch deine gepatchten Sourcen als tar.gz oder so zur Verfügung stellen? Hab grad arge Probs mit dem grsec 2.0!

Könnte ich tun, wüsste aber gerade ehrlich gesagt nicht, was das bringen sollte (mal ganz davon abgesehen, dass das ein verdammt großer Tarball wäre). ;)
Was für Probleme hast du denn damit?

Ich habs nicht geschafft, den aktuellen grsec-Patch mit patch anzuwenden, da läuft er immer in ein paar Fehler (Kernel Source von Backports.org.)
Wie war nochmal der Befehl, den Patch als Kernel-Patch-Paket unter Debian zu erstellen?

FTPFS hat auch irgendwelche Probs mit der IPv6-Version gehabt, da hab ich heut nacht mit append-Version usw. nicht mehr durchgeblickt, war schon spät. Kleiner Tip?

make-kpkg modules_image --revision=1 hat für den normalen Kernel hingehauen, auch irgendwie mit nicht korrekt angewandtem GRsec-Patch.
Ich hätte halt gerne deine Sourcen gehabt, damit ich mir sicher bin, einen ordnungsgemäß gepatchten GRsec-Kernel bauen zu können wenn ich das möchte.

Und dann halt das IP6-Problem, ich muss mir das heute mittag nochmal reinziehn. Hilfe wäre nicht schlecht ;-)

Danke!
ff

[tic]

Kaum hat man ne neue Platte und eine lange Nacht hinter sich geht der Kernel einwandfrei :)
Gäähn.

Leute bin ich froh dass es Backup gibt 8O

Na immerhin hab ich jetzt wieder eine neuere Version von so ein paar Spezialkandidaten.

[ffl]

Wenn jemand Interesse an den bereits gepatchten Kernelsourcen hat (grsec 2.0), ihr findet ihn hier:

http://www.rootservices.de/dh-kernel/

Danke an CaptainCrunch, der ihn mir freundlicherweise zur Verfügung gestellt hat.

[as-n]

Hallo,

wollte mir gerade den 2.4.26er mit grsec kompilieren, aber nun kommt dies:

Code: Select all

kernel/kernel.o: In function `sys_setregid':
kernel/kernel.o(.text+0x10d0b): undefined reference to `gr_check_group_change'
kernel/kernel.o: In function `sys_setgid':
kernel/kernel.o(.text+0x10e0c): undefined reference to `gr_check_group_change'
kernel/kernel.o: In function `sys_setreuid':
kernel/kernel.o(.text+0x1101d): undefined reference to `gr_check_user_change'
kernel/kernel.o: In function `sys_setuid':
kernel/kernel.o(.text+0x1119c): undefined reference to `gr_check_user_change'
kernel/kernel.o: In function `sys_setresuid':
kernel/kernel.o(.text+0x11370): undefined reference to `gr_check_user_change'
kernel/kernel.o: In function `sys_setresgid':
kernel/kernel.o(.text+0x115d0): undefined reference to `gr_check_group_change'
kernel/kernel.o: In function `sys_setfsuid':
kernel/kernel.o(.text+0x11793): undefined reference to `gr_check_user_change'
kernel/kernel.o: In function `sys_setfsgid':
kernel/kernel.o(.text+0x118af): undefined reference to `gr_check_group_change'
fs/fs.o: In function `compute_creds':
fs/fs.o(.text+0xc4fd): undefined reference to `gr_check_user_change'
fs/fs.o(.text+0xc533): undefined reference to `gr_check_group_change'
make: *** [vmlinux] Error 1

Ich habe die alte .config genommen, make oldconfig und dann normal kompilieren lassen, was habe ich denn da jetzt wieder vergessen?

Ciao
André