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.
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.
Nun in dem Debian DSA wurden gleich mehrere Probleme geloest und behoben. Die Frage ist: warum wurde da beim lokalen Root-Exploit so lange gewartet ? Wenn kleinere Luecken in einem Rutsch behoben werden, so kann ich damit leben. Aber ich finde lokale Root-Exploits so wichtig, das man damit nicht erst ca. 2 Monate warten sollte. Da ist sofort zu handeln und die kleineren Fehler aufzuschieben.
ACK. Vielleicht sahen das im Fall von ptrace angesichts der Probleme mit dem Patch nicht alle so.
[ ] Du weißt, was "stable" bei Debian GNU/Linux bedeutet.
Nein. Nicht genau. Hast du dafuer einen Link parat ?
Ähm, im Moment leider nicht. Ich hatte vor Kurzem erst dazu eine gute Beschreibung gefunden, aber was man nicht bookmarkt ... ;-)
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.
Auf der Seite klang's besser ;-)
Freundlich grüßend, Erik