Neue Sicherheitslücke im Linux-Kernel

[evoluzzer]

und mal wieder der Kernel....
http://www.heise.de/newsticker/data/dab-05.01.04-002/

[captaincrunch]

... aber ausnahmsweise mal mit schnellem Fix: http://lkml.org/lkml/2004/1/5/80

bzw. http://www.kernel.org/diff/diffview.cgi ... 4.bz2;z=16

[crasline]

wollt ihr nicht wieder einen debianhowto kernel mit grsec machen? :)


Denn der ist ja scheinbar auch betroffen ..

[silv]

hmm .. nicht unbedingt .. hab den grsecsource vor ner weile mal in der richtung überflogen und wird einiges beim mem und vmem handling geändert .. zumindest durch die pax-features werden ansatzpunkte für exploits erschwert wenn nicht verhindert ... müsste man aber mal in ruhe analysieren ..

nichts desto trotz empfiehlt sich natürlich nen update .. aber im bereich der local exploits gibts weitaus einfacher zu nutzende schwachstellen .. von daher ist vorsicht gut aber panik übertrieben ..

just my 2 cents ..

.. silv

[captaincrunch]

wollt ihr nicht wieder einen debianhowto kernel mit grsec machen?

Wie schon von silv gesagt betraf der GRSecurity-Patch, der im aktuellen 2.4.23er-Debianhowtokernel enthalten ist ein paar der Memory-Handler angefasst worden, u.a. auch genau das File, um das es geht.
Ich bin gerade dabei, das ganze einmal näher zu untersuchen, u.U. war der gute Spender schon so geistesgegegnwärtig, das schon zu fixen. Sobald ich da mehr weiß, gibt's eine Meldung an dieser Stelle.

aber im bereich der local exploits gibts weitaus einfacher zu nutzende schwachstellen .. von daher ist vorsicht gut aber panik übertrieben ..

Hat man do_brk() auch gedacht, und mittlerweile habe ich ein paar Kisten gesehen, die mit entsprechenden Explots geknackt wurden. ;)

[crasline]

Ich bin gerade dabei, das ganze einmal näher zu untersuchen [..]

Echt super von dir .. schonmal danke! :)

[captaincrunch]

Momentan sieht's so aus, als wäre der betroffene Code ohnehin schon durch den Patch geändert:

Original:

Code: Select all

                if (new_len > TASK_SIZE || new_addr > TASK_SIZE - new_len)
                        goto out;

Nach dem Patch:

Code: Select all

#ifdef CONFIG_GRKERNSEC_PAX_SEGMEXEC
        if (current->flags & PF_PAX_SEGMEXEC) {
                if (end > SEGMEXEC_TASK_SIZE)
                        return -EINVAL;
        } else
#endif

Der Code ist also ein grundlegend anderer, wobei ich auf die Schnelle mit meinen mageren C-Kenntnissen da (noch) nicht ganz durchsteige. Ich suche trotz allem noch weiter. Falls jemand schon POC "in the wild" gesichtet hat, bitte direkt an mich. ;)

[captaincrunch]

So, nach drei erfolglos ausgeführten Exploit-Varianten kann ich für heute erstmal beruhigt schlafen gehen: der Debianhowto-Kernel inkl. GRSecurity scheint (für's erste) verschont geblieben zu sein, da PaX diese Art "Angriff" verhindert.

Morgen gibt's mehr.

[lufthansen]

willst du die poc mal uppen ?

[captaincrunch]

Vorerst mal nicht, sorry. Hint: einer geistert ohnehin schon auf Full-Disclosure rum, an den anderen beiden wurde seit gestern abend ohnehin noch rumgefeilt, und es dürfte ohnehin nicht mehr lange dauern, bis die Scriptkids die Dinger in die Hände bekommen. :(

Frag mich das einfach noch mal, wenn ich 100%ig sicher bin, dass "mein" Kernel nicht betroffen ist, OK?

[silv]

Momentan sieht's so aus, als wäre der betroffene Code ohnehin schon durch den Patch geändert:

Der Code ist also ein grundlegend anderer

jain .. der zugrundeliegende Code ist kein anderer ...

grsec ändert die Zuweisung auch nur wenn pax_segmexec enabled ist .. andernfalls greift der unveränderte mremap Code

zumindest an dieser Stelle wird von grsec auch nicht explizit die Möglichkeit eines creates von 0byte VMAs ausgeschlossen .. und genau hier liegt eben das Problem

da mit unterschiedlichem Handling gearbeitet wird kann man vermuten das ein "vanilla" poc oder auch final-script-kid exploit nicht unverändert auf einem grsec- pax_segmexec enabled Kernel lauffähig ist ... wahrscheinlicher wird dies jedoch erst durch das nachfolgende Handling der Mempages durch grsec pax Features verhindert ( wieder vorrausgesetzt das diese enabled sind ) ...
ne Mempage mit der man was machen könnte ist nur der Anfang .. ohne sinnvolle Injection - oder exec Möglichkeit führt eine Ausnutzung des Flaws dann aber zumindest zu Kopfzerbrechen bei der Umsetzung :)


auf Deutsch und damit für die meisten hier der wichtige Teil :) .. grsec -as is- gibt keine abschliessende Sicherheit .. der existierende Patch für mremap ist trotzdem anzuraten da ich nicht annehme das die Mehrzahl der User grsec "richtig" configuriert hat .. dort liegt meines Erachtens auch die größte Schwäche von grsec und vergleichbaren Patches bzw. das größte Problem Userseitig .. Grsec kann den vanilla um ein gutes Stück "sicherer" machen .. allerdings auch nur wenn man weiss was die einzelnen Optionen bewirken.

.. aber ist das nicht immer so :)

.. just my 2 cents ...


p.s. als Hinweis .. ich habe mir nicht die Kernelconfig aus dem DebianHowto auf welches hier verwiesen wurde angeschaut ... bei entsprechender Config ändert dieses tatsächlich den Ansatz für eine Ausnutzung von mremap Flaws bzw. verhindert diese ggf. auch. Hier kann sich ja jemand dazu äußern der das System laufen hat und/oder einer der Autoren

-Edit-
z.t. sind auch Kernel ohne grsec nicht betroffen .. zb. enthalten die -aa Patches größere Ã?nderungen im VM-Handling

Ist insbesondere für diejenigen interessant welche mehr als nur vanilla und ggf. grsec Installiert haben .. jeder Kernelpatch zuviel macht Sachen die man vielleicht garnicht will :)

Ich hab schon Serverkernel mit 5mb additional Multimediapatches gesehen ;)

[captaincrunch]

grsec ändert die Zuweisung auch nur wenn pax_segmexec enabled ist .. andernfalls greift der unveränderte mremap Code

...was bei besagten Kernels der Fall ist. ;)

wahrscheinlicher wird dies jedoch erst durch das nachfolgende Handling der Mempages durch grsec pax Features verhindert ( wieder vorrausgesetzt das diese enabled sind ) ...

... was auch der Fall ist. ;)

ohne sinnvolle Injection - oder exec Möglichkeit führt eine Ausnutzung des Flaws dann aber zumindest zu Kopfzerbrechen bei der Umsetzung

... was auch Linus selbst so sieht: http://lkml.org/lkml/2004/1/5/310 ;)

grsec -as is- gibt keine abschliessende Sicherheit .. der existierende Patch für mremap ist trotzdem anzuraten da ich nicht annehme das die Mehrzahl der User grsec "richtig" configuriert hat

Leider spielen der mremap-Patch und GRSecurity/PaX nicht 100%ig zusammen, aber immerhin gibt's schon einen angepassten GRSecurity-Patch: http://forums.grsecurity.net/viewtopic.php?t=648 (ganz unten)
In Falle des "Debianhowto-Kernels" sind die Optionen jedenfalls so gesetzt, dass sämtliche aktuellen POCs fehlschlagen.

[silv]

... was auch Linus selbst so sieht: http://lkml.org/lkml/2004/1/5/310 ;)

bin ich ja in guter gesellschaft ;)

[captaincrunch]

So, für alle Testwilligen (da ich bislang immer noch keinen "echten" Exploit gesehen habe):

Unter http://deb.debianhowto.de/dists/testing ... nary-i386/ liegen die soeben fertiggestellten Kernel-Images für den 2.4.24er inkl. GRSecurity.

Diejenigen, die ohnehin schon den richtigen Eintrag in der sources.list haben, können ganz einfach per apt-get usw. updaten.

Wie gehabt gibt's wieder mal 2 verschiedene Images: eins mit, eins ohne IPv6-Support. ReiserFS ist als Modul dabei, die drei bekannten Netzwerkkarten sind ebenso als Module vorhanden. Bei den Realtek-Karten ist darauf zu achten, dass das Modul jetzt nicht mehr "rtl8139", sondern 8139too heißt, also am besten vorher in die /etc/modules eintragen wenn nicht schon passiert.

Beide Images sind allerdings noch nicht als "extensiv getestet" zu bezeichnen, da die Ã?nderungen zum 2.4.23er (mit dem ich sehr zufrieden bin) aber marginal sind, düften keine großen Probleme zu erwarten sein. Die Nutzung geschieht aber (wie immer ;) ) auf eigene Gefahr.
Feedback dazu bitte in einem eigenen Thread.

[footh]

Hallo!

Wie sieht`s bei dem Yast-Suse-Update aus, kann man beruhigt diesen Kernelfix installieren ohne danach gleich wieder Angst haben zu müssen, daß beim nächsten Boot der Server wieder wegbleibt?

MFG
footh

[lufthansen]

@ cc
mir is von
Copyright (C) 2004 Christophe Devine and Julien Tinnes
ein poc in die mail box geflogen gekommen ..
hast du den schon ?

[Joe User]

Wie sieht`s bei dem Yast-Suse-Update aus, kann man beruhigt diesen Kernelfix installieren ohne danach gleich wieder Angst haben zu müssen, daß beim nächsten Boot der Server wieder wegbleibt?

Nein!

[Joe User]

hast du den schon ?

Ja, den hat CC zeitgleich mit uns und x-tausend anderen bekommen ;)

[pf4]

Alle bis auf ich :(

Also wie sieht jetzt aus mit dem Kernel, is nen Update notwendig ?



PS: Kann mir einer das ding zusenden Mail per PM

[footh]

Hallo!

Tja, meine Befürchtung traf ein
Auch wenn es wahrscheinlich nicht sein kann, nach dem Einspielen über Yast des neuen Fixes blieb der Server nach einem Reboot weg.

Nach einspielen des alten Kernels kam er wieder. :roll:


MFG
footh

[captaincrunch]

Ja, den hat CC zeitgleich mit uns und x-tausend anderen bekommen

Nicht ganz, sondern (kurz vor der Veröffentlichung) direkt von der "Quelle". ;) Dieser ist aber laut mehreren Aussagen der "gefährlichste" bislang im Umlauf befindliche POC.

[static]

Hi,
wollte nur kurz mitteilen, dass für Debian Woody die offiziellen Kernelpakete mit dem Fix released wurden.

so long
static