🚀 go-pugleaf

root@chshost.in-berlin.de (Thomas Liening) writes:
> [...]
> Dies ist die eine und sicherlich wichtigere Seite der Medaille. Ich hatte
> aber auch schon mal einen Fall, bei dem mich exakt ein solcher Bug davor
> bewahrt hat, auf meinem System eine komplette Neueinrichtung eines ISC-
> Systems - verbunden mit erheblichen Datenverlusten - durchfuehren zu muessen.
> Dabei hatte ich als root mit "vi /etc/passwd" eine andere Shell fuer den
> root-Account eingetragen, die allerdings tatsaechlich gar nicht mehr auf
> der Platte vorhanden war. Unmittelbar danach hatte ich das System herunter-
> gefahren und konnte mich nach dem naechsten Reboot nicht mehr als root
> einloggen. Nur durch Ausnutzung einer Sicherheitsluecke gelang es mir,
> wieder als Superuser in die Kiste reinzukommen.

Hm, Du hast doch sicherlich eine Bootdiskette mit der Du Dein System
mal zum Installieren hochgefahren hast. Falls Du im dortigen Kernel
die notwendigen Treiber hast kannst Du von dieser Diskette booten.
Anschliessend noch etwas mounten und den Rest kannst Du Dir sicher
denken.

> Deswegen finde ich es _als Betreiber eines niemandem ausser mir zugaeng-
> lichen Unix-Systems_ sehr praktisch, wenn man Kenntnis auch ueber das
> zum Einbruch noetige Verfahren bekommt. Allgemein gesehen ist es nichts-
> destotrotz unverantwortlich ... nur wie sollte man sicherstellen, dass 
> nur "berechtigte" Sysadmins die entsprechenden Informationen erhalten?
> Denn andererseits: Was nutzt es mir, wenn ich den Weg nur Sicherheits-
> organisationen erklaere, die dann vielleicht irgendwann mal den Hersteller
> des Systems informieren, der seinerseits eventuell irgendwann vielleicht
> einen Bugfix dafuer erstellt? 

Und wer garantiert Dir, dass die Sicherheitsorganisation die ihr
bekannten Informationen nicht "zweckentfremdet" ?
Da ist mir die Veroeffentlichung noch lieber.

-- 
-- 
Ralf Wenk -- ralf@ptavv.ka.sub.org