Am 10. Februar 2004 schrieb Martin Weissbach:
"Erik Schanze" Schanzi_@gmx.de wrote:
Jens Lorenz:
Erik Schanze wrote:
Das dabei Debian auch seine Fehler hat und man nicht in der Lage war einen Patch für den ptrace() Kernel Bug einzuspielen der bereits seit über 2 Monaten behoben war, und damit dann mit einem Angriff "belohnt" wurde, das beispielsweise interessiert scheinbar niemanden...
[ ] Du hast den zeitlichen Ablauf der Ereignisse überblickt. [1]
Sorry, aber dein Link enthaelt Ausfuehrungen zum Angriff auf die Debian-Server mittels der Sicherheitsprobleme in do_brk(). Martin denkt hier eher an die ptrace()-Race-Condition aus dem letzten Jahr.
Martin bringt aber beides in einen Zusammenhang und das stimmt so nicht.
Nein habe ich nicht. Ich habe wenn du meine Postings mal richtig lesen würdest nur von dem ptrace() Bug gesprochen. Du hast mit do_brk() angefangen.
Aha, es gab also einen erfolgreichen Angriff auf einen Debian Server unter Ausnutzung des ptrace()-Bugs. Wann war der?
Dazu kam fuer Debian das DSA-311 am 8. Juni 2003. http://www.debian.org/security/2003/dsa-311 Dieses zitiert ganz oben ein Advisory vom 17. Maerz 2003. http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0134.html SuSE gab dazu ein Security Anouncement am 25. Maerz 2003 heraus (wozu Updates gehoerten). http://www.suse.de/de/security/2003_21_kernel.html
Das hat mir damals auch nicht gefallen. Der gleich angebotene Patch war aber auch wegen seiner (zum Teil unbekannten) Auswirkungen auf andere Programme nicht unumstritten. Einfach einspielen und gut, war leider nicht möglich.
Stattdessen lieber Monate warten?
Besser als vorschnell Patches einspielen, die unbekannte Seiteneffekte haben. Das Gschrei wäre genauso groß, wenn plötzlich Programme, die mit dem Patch nicht klarkommen, nicht mehr funktioniert hätten.
Im groben: Nach einem Feature-Freeze darf in ein testing, das stable werden soll kein zusätzlicher Code einfließen, der mehr tut, als Sicherheitsrelevante oder releasekritische Fehler zu beheben, d h. keine neuen Funktionen. Wenn es stable wurde, dürfen nur noch sicherheitsrelevante Fehler und fehlerhafte Funktionen behoben werden, ohne neue Features einzubauen. Dadurch kann der Admin, der ein "apt-get update ; apt-get upgrade" macht, sicher sein, dass alle Pakete weiterhin zusammenspielen und sein System nicht z. B. an einer geänderten API eines Programms zerbricht.
Dann habe ich ja den Sinn von stable doch richtig verstanden, denn genau davon habe ich geredet. Ich habe gemeint das ein System für mich _nicht_ stable genannt werden darf, wenn man Monate lang wartet um es gegen Kernel Schwachstellen zu sichern.
Was ist stabiler: Ein Kernel mit einer lokal ausnutzbaren Schwachstelle, oder ein gepatchter Kernel, mit dem evtl. vorhandene Programme nicht mehr wie gewohnt funktionieren?
Nebenbei: Was hast du unternommen, um bei der Behebung dieses oder anderer Fehler zu helfen? Auch immer nur "monatelang gewartet"? Meckern sollte nur der, der es besser machen kann.
Freundlich grüßend,
Erik