Sollen wir die Diskussion also wiederholen, ja? Eigentlich ging ich davon aus, die Frage sei geklärt, aber irgendwie scheint sich doch immer wieder jemand berufen zu fühlen, Linux-Bugs um jeden Preis zu relativieren.
Jemand, der aus welchem Grund auch immer einen Account auf diesem Rechner hatte, welcher kein root-Account war, konnte durch ein Kernel-Bug seinen Nicht-root-Account dazu benutzen, Dinge zu tun, die sonst nur root kann. Das ist ein Kernel-Bug ist ein Kernel-Bug ist ein Kernel-Bug.
Es ist genau umgekehrt: Das wirklich fehlerbehaftere ist selbstverständlich sehr wohl CVE-2006-2451, ohne CVE-2006-2451 hätte diese Person nämlich gar nichts schädliches anrichten können.
Aber relativier ruhig weiter - dass Du damit das Sicherheitskonzept von Linux bzw. UNIX ins Lächerliche ziehst, merkst Du wahrscheinlich gar nicht mehr. Selbstverständlich ist es ein Bug und kein Benutzerproblem, wenn ein Benutzer seine Rechte erhöhen kann, und das ist nicht zu relativieren.
Nein, die Frage wird wohl nie geklärt sein, da es immer wieder Menschen geben werden, die im Gegensatz zu Dir eine subjektive Meinung haben und nicht immer vollkommen objektiv die Dinge bewerten. Deshalb wird es wohl auch immer Leute geben die einfach behaupten, daß der Kernel-Bug nur ausgenutzt werden konnte, weil der Angreifer sich schon durch ein unsicheres Passwort auf dem Rechner war - immerhin ist das ja auch die Aussage der Debian-Crew. Andererseits hast Du bislang aber auch noch nicht dargelegt, daß der Kernel-Bug auch ohne den bereits erfolgten Angriff auf den Benutzeraccount möglich gewesen wäre. Vielleicht solltest Du dort noch eine Quellenangabe einfügen, die die Debian-Behauptung wiederlegt, das könnte helfen. Solange werden die meisten Leute es wohl weiterhin als eine Kombination aus Benutzerproblem und Kernelbug ansehen, mit unterschiedlicher Gewichtung selbstverständlich.
> Andererseits hast Du bislang aber auch noch nicht dargelegt, > daß der Kernel-Bug auch ohne den bereits erfolgten Angriff > auf den Benutzeraccount möglich gewesen wäre.
Das braucht auch niemand gesondert darzulegen, es steht nämlich direkt in CVE-2006-2451, wo es jeder nachlesen kann.
Jeder mit einem lokalen Benutzerkonto hätte das ping-Binary überschreiben können, und an ein lokales Benutzerkonto zu kommen, setzt nicht zwingend einen technischen Angriff voraus. Es gibt auch sowas wie "Social Engineering" (d.h. man könnte z.B. versuchen, durch bewusst geknüpfte Beziehungen ganz ohne technische Mittel an ein Benutzerkonto zu kommen).
es war eben nicht ein fehler des Kernel teams, weil diese den bug längst gefixt hatten. debian hatte seinen server nicht aktualisiert, und das war die zeitbombe die dann auch gezündet hatte.
> Ich hab deinen Beitrag mal übersichtlicher gestaltet.
Nein, Du hast Dich ins Bodenlose blamiert.
> Die Lücke war extrem leicht zu schliessen... Userfehler.
Manch einer wird es nie begreifen. Ein Bug bleibt auch dann immer noch ein Bug, wenn es einen Fix gibt. Dann ist es ein sog. gefixter Bug. Dadurch geht der Bug als solcher aber nicht auf, ein Bug zu sein.
Oh, da ist wohl jemand, der es pflegt, für andere zu sprechen und etwas, das er selbst persönlich vorher im Konjunktiv formulierte, zur Tatsachenfeststellung zu erheben. Diese Sorte mag ich ganz besonders. Mehr davon, bitte!
Der fragliche Entwickler-Account wurde möglicherweise durch ein leicht zu erratendes Passwort kompromittiert. Eine Überprüfung aller Entwicklerkonten deckte eine weitere Anzahl zu schwacher Passwörter auf. Diese Konten wurden bis auf weiteres gesperrt.
es wurde gestern schon gemeldet, dass möglicherweise ein Passwort nicht sicher war!
Aber GeWe muss ja wieder mal den Troll spielen und einfach drauf losblubbern !
es wurde gestern schon gemeldet, dass möglicherweise ein Passwort nicht sicher war! Ja und? Selbst dann sollte so etwas nicht vorkommen. Der Administrator hat dafür zu sorgen, dass kein Benutzer dem System Schaden zufügen kann, d.h. er hätte den 2.6.16.24 einspielen müssen.
Von Amtsleiter Merkbefreiung am Fr, 14. Juli 2006 um 13:41 #
Die Tatsache das sich G.W. nicht gerade allergrößter Beliebtheit erfreut, ändert genau nichts daran, daß auf der Kiste ein Kernel mit bekannt kaputtem Code lief. Wenn es in meiner Bude rumpelt werd ich sagen: "Nee Cheff, ich kann nichts dafür. G.W. hat gesagt ich hätte Schuld. Und der ist bekanntlich doof und deshalb ist hier alles in Butter." Na, das ist doch leichter als Löcher stopfen.
Warum man Aussagen, auf die man sich bezieht, zitieren sollte? Ganz einfach: Weil es bei persönlichen Bemerkungen immer sehr vorteilhaft ist zu belegen, auf welche Aussagen sie sich beziehen. Ansonsten ist es einfach zu offensichtlich, dass es ausschließlich ums Persönliche geht.
Von dem langhaarigen Unixfossil am Fr, 14. Juli 2006 um 15:50 #
Kernelbug ist Kernelbug.
Wären alle User brav und hätten alle User sichere Passwords, wäre wohl Nichts passiert. Sicherheit ist eine Zwiebel. Es mussten mehrere Verteidigungringe fallen, um diesen "Skandal" zu erzeugen. Soll ich dem BND nun mal mehrkreisige Skizzen machen? Ööööö das war ein anderes Thema. Na gut!
Interessant finde ich, wie ein Befürworter des meistkompromitierten OS dieses nun Ausschlachtet, jedoch ändert auch eine Kritische Distanz zu ihm nichts daran, daß ein Kernelbug nunmal ein Kernelbug ist.
Da hast Du Recht: Das "wirklich" hätte man sich sparen müssen. Er meinte wohl, dass es ohne den menschlichen Fehler den lokalen Login auf einen so wichtigen Rechner zuzulassen, nicht möglich gewesen wäre.
Aber Du hast auch Unrecht: Der Linux-Kernel hat mit Garantie noch jede Menge bekannte und unbekannte Probleme, die das gleiche gestatten.
Die Fragen sind doch:
1. Wie konnte es sein, dass der Fix von CVE-2006-2451 nicht auf dem Rechner installiert war, obwohl schon länger verfügbar? Eindeutig ein menschliches Problem. 2. Wie konnte jemand für einen so wichtigen Rechner ein zu schwaches Passwort einsetzen? Eindeutig ein menschliches Problem. 3. Wie konnte das unbemerkt bleiben? Eindeutig ein menschliches Problem, denn die Reaktion zeigt, dass es möglich war, jetzt diese Fälle durch zu scannen.
Du solltest begreifen, dass man immer davon ausgehen wird müssen, dass es solche Fehler im Linux-Kernel gibt und deshalb der Zugriff als Linux-User auf der Maschine einem besonderen Schutz unterliegen muss, der der Wichtigkeit des Rechners angemessen ist. Du solltest begreifen, dass man ferner auch immer entfernte Angriffe wird machen können.
Haupt-Probleme an Bugs folgende:
a) Mit der Veröffentlichung des Fehlers oder seiner Korrektur, wird jeder Böswillige sofort in die Lage versetzt, eine Analyse zu machen, wie er das Ausnutzen kann, bei Systemen, die nicht die Korrektur haben.
b) Es gibt keine nicht-triviale oder fehlerfreie Software. Keine Methode kann diese erstellen.
Das Wichtigste ist daher immer der Umgang des Menschen mit den fehlerhaften Systemen. Die Vermeidung der Exposition des Systems wo es nur geht.
Die Logins der Entwickler müssen besser geschützt werden. Aber seiner Natur gemäss, hat Debian das Problem aus vielen Leuten zu bestehen, die alle auch individuelle Fehler machen.
Im Grunde finde ich aber brilliert Debian hier. Das Problem wurde gelöst, bevor es richtig anfing zu existieren. Konkrete Erkenntnisse führen dazu, dass alle Accounts jetzt sicherere Passwörter haben müssen. Und man macht den Umgang mit dem Problem öffentlich.
Nur so kann ich Debian vertrauen, hm, obwohl ich ja nun Kubutu Edgy benutze :p
Meine Nutzer haben bei der Auswahl ihrer Passwörter gewissen Anforderungen zu genügen. Die betreffende Maschine hatte wohl keinen Administrator? Nunja, unsichere Authentifizierung schein politisch weniger brisant als kaputter Code. Insofern ist das Projekt jungfräulich rein. MUAHAHAHA
Der Angreifer findet keine bekannten Bugs? Sacht mal was ist hier eigentlich los? Ferien, Politik oder was? Auch für den letzten der es nicht höhren will. Das Betriebssystem lief mit ungefixtem Kernel. Der Admin betrieb wissentlich ein verwundbares Sytem. Da hing eine kaputte Kiste am Netz. Immernoch fragen? Ja? Sie sind gefeuert. Und sie können sicher sein, nach der Kanone die sich geleistet haben können sie sehr lange nach nem neuen Job oder Kunden suchen.
@fuffy War nicht persönlich gemeint. Ich krieg da nur die Krise wenn jemand wissentlich ein fehlerhaftes System betreibt und dann rumfenzt und vom eigenen Versagen ablenkt. Da war der Puls leider etwas hoch, sry.
Der Angreifer findet keine bekannten Bugs? Wenn der Angreifer ein frustrierter Debian-Entwickler gewesen wäre, dem der lokale Login gestattet worden wäre, hätte auch das sicherste Kennwort nichts gebracht, wenn dieser die Lücke im Kernel ausgenutzt hätte.
Das Betriebssystem lief mit ungefixtem Kernel. Das habe ich schon weiter oben geschrieben.
Der Admin betrieb wissentlich ein verwundbares Sytem. Da hing eine kaputte Kiste am Netz. Ja, eben. Genau das ist das Problem, nicht unsichere Benutzerkennwörter. Unsichere Benutzerkennwörter dürfen, wenn überhaupt, nur dazu führen, dass der betreffende Account kompromittiert wird. Das System an sich darf dadurch nicht in Leidenschaft gezogen werden. Ein Administrator hat das System vor den eigenen Benutzern zu schützen, sonst könnte man Benutzern gleich sämtlichen Benutzern die UID 0 zuteilen.
Laege der Fehler auch am User, wenn sich einer der Entwickler, strebend nach der Macht des roots auf ``Gluck'', die Luecke im Kernel zu Nutze gemacht haette? Waere dann nicht auf einmal doch der Kernel daran Schuld gewesen, dass ``Gluck'' kompromittiert werden konnte?
Der Kernel hatte diese Luecke; dass nun wahrscheinlich ein zu schwaches Benutzerpasswort jemandem die Moeglichkeit gegeben hat, diese Luecke auszunutzen, mag zwar stimmen, aber ohne die Luecke im Kernel waere es nie so weit gekommen. Von daher ist auch der Kernel wirklich fehlerbehaftet gewesen, und daran aendert auch nicht die Tatsache, dass der Bug leicht behebbar gewesen ist -- er war da und er wurde genutzt.
Das ist echt eine blöde Sache mit den Mehrbenutzersystemen. So schnell kann ein Administrator ja gar nicht sein wie es nötig ist. Wenn heute um 14:00 Uhr eine Lücke bekannt wird, der Hacker aber bereits Zugang zum System hat, dann hat der Admin keine Chance.
Was sind also die Lösungen ?
Nie wieder Lücken im Kernel und sonst wo ? Unrealistisch Besseres IDS ? Da ist es schon zu spät, auch wenn es im Nachhinein hilft RW remount von /usr nur mit über Serielle Konsole erlauben, würde das gehen ? Root Erlaubniss nur wenn man einen entsprechenden Key hat den man auch remote per ssh verwenden kann ? Würde doch sicher helfen oder ?
Auf jeden Fall ist wohl auf den Debian Servern spätestens ab jetzt eine Überprüfung der Passwörter bei Erstellung und Änderung gefragt. Genauso wie der Abgleich der Prüfsummen aller Dateien in $PATH mit einer externen sicheren readonly Liste.
Wobei das nicht heissen soll das Debian das Kernel Update nicht hätte schneller aufspielen können und damit vieleicht zumindest diesen Einbruch hätte verhindern können. Das oben ist eher eine generelle Frage aus Interesse
SE Linux kapselt jeden Prozess (also auch User) in einer eigenen Domäne. Domänentransitionen sind nur durch _ausdrückliche_ Erlaubnis in der Policy möglich. Ein User kann sich auf SE Linux-gesicherten Systemen keine root-Rechte erschleichen, da z.B. Buffer Overflows nicht aus ihrer Domäne herauskommen. Beispiel: Ein Apache, dem über einen Buffer Overflow ein Injection Vector untergejubelt wurde stürzt zwar ab, da aber der Apache keine Shell starten darf (unter SE Linux darf zunächst einmal keiner irgendetwas), bleiben Exploits wirkungslos.
Es gibt nur 2 Haken: 1. SE Linux schützt nicht vor schwachem Root-Passwort 2. Die Administration ist eine echte Herkulesaufgabe (extrem komplexes Regelwerk)
Bleibt also nur zu hoffen, dass SE Linux schleunigst in Debian Einzug hält.
Hier ein wenig Lesestoff: http://www.computerwoche.de/knowledge_center/linux/558221/ http://www.nsa.gov/selinux/
Wer sich beweisen will: http://www.coker.com.au/selinux/play.html Und hier Russel Cokers Doku zur Playmachine: http://www.selinux-symposium.org/2005/presentations/session7/7-1-coker.pdf
Das stimmt, SE Linux ist eine der Techniken die auf jeden Fall helfen würden. Wenn auch hier im Cron Fall nicht, oder ? Hmmm ... ich muss gestehen, ich bin mir nicht sicher ;-) Ob SE Linux hier helfen kann müsste man wissen, wie genau der Dump geschieht. Wenn dies ein Prozess aus dem Userspace übernimmt, sehe ich da gute Chancen. Für den Fall, dass der Kernel selbst das macht habe ich so meine Bedenken. Ich vermute aber, dass man Cron davor bewahren könnte, die Datei zu starten (denn für sie existiert ja keine Policy-Regel)
Von einem göttlich unmutenden User am Fr, 14. Juli 2006 um 12:53 #
Eigentlich kann es doch nicht so schwer sein das Paßwort beim Anlegen durch eine Reihe regulärer Ausdrücke prüfen zu lassen und somit eine hohe Sicherheit zu erzielen. Irgendwie habe ich den Eindruck, daß in dem Debianprojekt doch nicht die allerbesten Köpfe der Linux-Szene arbeiten...
Was den Bug betrifft... -> Mit SuSE wäre das nicht passiert...
Das Debian Projekt hat sogar alle nötigen Pakete in der eigenen Distribution um sowas automatisch zu überprüfen. Und das ist dann weit besser als selbstgemachte Reguläre Ausdrücke.
Hätte es aber nicht für möglich gehalten, dass die sich da die Passwörter so frei auswählen dürfen, dass man sie per Dictionary Attacken rausbekommen kann...
Selbst dann hätte immer noch eine der Personen, die rechtmäßig Shell-Zugriff auf den Rechner haben, das System kompromittieren können. Es ist Sache des Administrators, dafür zu sorgen, dass ein normaler Benutzer (UID > 0) das System nicht lahmlegen kann. Wenn du zu deinen Benutzern vollstes Vertrauen hättest, könntest du ihnen gleich dein root-Kennwort geben.
Aufgabenstellung: neuer User bekommt Account. 0) Zugang per Passwort auf die Server wird abgestellt 1) User und Admin tauschen ihre GPG-Identitäten untereinander aus 2) User schickt Admin einen seiner öffentlichen SSH-Schlüssel und signiert die dazugehörige Email 3) Admin erzeugt Account und trägt den SSH-Schlüssel vom User in die authorized_keys ein 4) Admin schickt User die Accountdaten in verschlüsselter Email 5) Ein Jahr später muß (meinethalben über einen Emaildienst) ein neuer öffentlicher SSH-Schlüssel übermittelt werden 6) Account wird gesperrt, falls 5) nicht innerhalb eines Monats vor Ablauf des Jahres durchgeführt wird
Sobald Schritt 1 manuell durchgeführt wurde, kann der Rest komplett automatisiert werden und es fliessen keine Passwörter mehr.
Das Problem ist, das dies in einigen Ländern illegal ist, entweder aufgrund Patente oder Gesetzen gegen Privatsphäre/Verschlüsselungen. Debian will aber möglichst allen zugänglich sein, daher kommt eine solche Lösung nur schwer in Frage. Und Accounts 1. und 2. Klasse will keiner.
> Das Problem ist, das dies in einigen Ländern illegal ist Und trotzdem ist ein Login auf den Servern nur per SSH erlaubt? SSH verschlüsselt die Session auf beiden Seiten, also auch im Land, in dem Verschlüsselung verboten ist (wo eigentlich ausser in Russland und irgendwelchen Diktaturen?). Dann müßte man konsequenterweise auf jegliche Verschlüsselung verzichten und das ist nicht drin.
Such mal auf den debian-dev Listen, da gab es mal einen langen Thread dazu. Die Verschlüsselung selbst ist nicht das Problem, sondern die Verwendung von public keys. Einfache Passwörter sind erlaubt, weil man die per Beugehaft in Erfahrung bringen kann.
In den USA sind zB die guten alten PGP versionen verboten, da sie kein hintertürchen haben, demnach unknackbar sind ( außer man will alt und grau werden ). daraufhin hat man entsprechendes eingebaut und seitdem dürfen die neueren versionen in den USA verwendet werden. Un die USA ist ja wohl *hust* eine demokratie *kotter*
Hmm, Demokratie -- wurde nicht auch der Führer und seine braune Brut mehrheitlich gewählt? Der Spitzbart und der Dachdecker (bzw. ihr Verein) bekam auch 40 Jahre die Stimmenmehrheit, selbst wenn wir die zugemogelten abziehen. Später behaupten meine Nachbarn, sie durften 40 Jahre nicht frei wählen. Nun gut, vielleicht nicht ganz frei, aber sie hätten NEIN sagen können. Aber wozu, ist doch alles richtig, was aus Bonn/Berlin, Washington, Tel Aviv ... kommt. Ach ja, Linux & Co. -- es geht zielstrebig den Bach hinunter, ganz demokratisch.
> Die Lücke betrifft alle Kernel-Versionen von 2.6.13 bis 2.6.16.23 bzw. 2.6.17.3.
Das ist so nur für ungepatchte Kernel richtig. Die verschiedenen Distributionen, die ältere Kernel einsetzen, haben für diese meist schon lange entsprechend gepatchte Kernelupdates herausgebracht.
Sollen wir die Diskussion also wiederholen, ja? Eigentlich ging ich davon aus, die Frage sei geklärt, aber irgendwie scheint sich doch immer wieder jemand berufen zu fühlen, Linux-Bugs um jeden Preis zu relativieren.
Jemand, der aus welchem Grund auch immer einen Account auf diesem Rechner hatte, welcher kein root-Account war, konnte durch ein Kernel-Bug seinen Nicht-root-Account dazu benutzen, Dinge zu tun, die sonst nur root kann. Das ist ein Kernel-Bug ist ein Kernel-Bug ist ein Kernel-Bug.
Es ist genau umgekehrt: Das wirklich fehlerbehaftere ist selbstverständlich sehr wohl CVE-2006-2451, ohne CVE-2006-2451 hätte diese Person nämlich gar nichts schädliches anrichten können.
Aber relativier ruhig weiter - dass Du damit das Sicherheitskonzept von Linux bzw. UNIX ins Lächerliche ziehst, merkst Du wahrscheinlich gar nicht mehr. Selbstverständlich ist es ein Bug und kein Benutzerproblem, wenn ein Benutzer seine Rechte erhöhen kann, und das ist nicht zu relativieren.
Mit wem sprichst Du?
Sehr leid tut es mir, dass manch einer so derart hart getroffen ist, dass er aber auch wirklich immer persönlich werden muss.
Der Inhalt deiner Postings ist es jedenfalls nicht. Das Thema wird auch ohne Dich kontrovers diskutiert. Aber du darfst gerne weiterblubbern.
> daß der Kernel-Bug auch ohne den bereits erfolgten Angriff
> auf den Benutzeraccount möglich gewesen wäre.
Das braucht auch niemand gesondert darzulegen, es steht nämlich direkt in CVE-2006-2451, wo es jeder nachlesen kann.
Jeder mit einem lokalen Benutzerkonto hätte das ping-Binary überschreiben können, und an ein lokales Benutzerkonto zu kommen, setzt nicht zwingend einen technischen Angriff voraus. Es gibt auch sowas wie "Social Engineering" (d.h. man könnte z.B. versuchen, durch bewusst geknüpfte Beziehungen ganz ohne technische Mittel an ein Benutzerkonto zu kommen).
Ich hab deinen Beitrag mal übersichtlicher gestaltet.
PS: Die Lücke war extrem leicht zu schliessen... Userfehler.
Nein, Du hast Dich ins Bodenlose blamiert.
> Die Lücke war extrem leicht zu schliessen... Userfehler.
Manch einer wird es nie begreifen. Ein Bug bleibt auch dann immer noch ein Bug, wenn es einen Fix gibt. Dann ist es ein sog. gefixter Bug. Dadurch geht der Bug als solcher aber nicht auf, ein Bug zu sein.
es wurde gestern schon gemeldet, dass möglicherweise ein Passwort nicht sicher war!
Aber GeWe muss ja wieder mal den Troll spielen und einfach drauf losblubbern !
Allen anderen ein schönes Wochenende
Ja und? Selbst dann sollte so etwas nicht vorkommen. Der Administrator hat dafür zu sorgen, dass kein Benutzer dem System Schaden zufügen kann, d.h. er hätte den 2.6.16.24 einspielen müssen.
Wenn es in meiner Bude rumpelt werd ich sagen: "Nee Cheff, ich kann nichts dafür. G.W. hat gesagt ich hätte Schuld. Und der ist bekanntlich doof und deshalb ist hier alles in Butter."
Na, das ist doch leichter als Löcher stopfen.
*kopfschüttel*
warum sollte ich den Troll zitieren :-)
da ware ich lieber Abstand, vielecht ist der ansteckend!
Wären alle User brav und hätten alle User sichere Passwords, wäre wohl Nichts passiert.
Sicherheit ist eine Zwiebel.
Es mussten mehrere Verteidigungringe fallen, um diesen "Skandal" zu erzeugen.
Soll ich dem BND nun mal mehrkreisige Skizzen machen?
Ööööö das war ein anderes Thema. Na gut!
Interessant finde ich, wie ein Befürworter des meistkompromitierten OS dieses nun Ausschlachtet, jedoch ändert auch eine Kritische Distanz zu ihm nichts daran, daß ein Kernelbug nunmal ein Kernelbug ist.
Sicherheit heisst nicht nur Airbag vorne und ABS hinten, sondern ringsum sicher machen!
klar, Kernel-update wäre schon besser gewesen, aber das heißt nicht alles andere außeracht zu lassen.
>meistkompromitierten OS dieses nun Ausschlachtet...<
lass mal den µ$- Nachtwächter doch blubbern, irdendwann wacht der auch mal auf .-)
Nur ein Millionstel eines Dollars? Mehr ist nicht drin? Das ist aber schade.
> einfach drauf losblubbern !
Du scheinst da irgendeinen "GeWe" mit "2old4these" zu verwechseln, darfst aber selbstverständlich gerne weiterblubbern.
Aber Du hast auch Unrecht: Der Linux-Kernel hat mit Garantie noch jede Menge bekannte und unbekannte Probleme, die das gleiche gestatten.
Die Fragen sind doch:
1. Wie konnte es sein, dass der Fix von CVE-2006-2451 nicht auf dem Rechner installiert war, obwohl schon länger verfügbar? Eindeutig ein menschliches Problem.
2. Wie konnte jemand für einen so wichtigen Rechner ein zu schwaches Passwort einsetzen? Eindeutig ein menschliches Problem.
3. Wie konnte das unbemerkt bleiben? Eindeutig ein menschliches Problem, denn die Reaktion zeigt, dass es möglich war, jetzt diese Fälle durch zu scannen.
Du solltest begreifen, dass man immer davon ausgehen wird müssen, dass es solche Fehler im Linux-Kernel gibt und deshalb der Zugriff als Linux-User auf der Maschine einem besonderen Schutz unterliegen muss, der der Wichtigkeit des Rechners angemessen ist.
Du solltest begreifen, dass man ferner auch immer entfernte Angriffe wird machen können.
Haupt-Probleme an Bugs folgende:
a) Mit der Veröffentlichung des Fehlers oder seiner Korrektur, wird jeder Böswillige sofort in die Lage versetzt, eine Analyse zu machen, wie er das Ausnutzen kann, bei Systemen, die nicht die Korrektur haben.
b) Es gibt keine nicht-triviale oder fehlerfreie Software. Keine Methode kann diese erstellen.
Das Wichtigste ist daher immer der Umgang des Menschen mit den fehlerhaften Systemen. Die Vermeidung der Exposition des Systems wo es nur geht.
Die Logins der Entwickler müssen besser geschützt werden. Aber seiner Natur gemäss, hat Debian das Problem aus vielen Leuten zu bestehen, die alle auch individuelle Fehler machen.
Im Grunde finde ich aber brilliert Debian hier. Das Problem wurde gelöst, bevor es richtig anfing zu existieren. Konkrete Erkenntnisse führen dazu, dass alle Accounts jetzt sicherere Passwörter haben müssen. Und man macht den Umgang mit dem Problem öffentlich.
Nur so kann ich Debian vertrauen, hm, obwohl ich ja nun Kubutu Edgy benutze :p
Gruß, Kay
Das Betriebssystem lief mit ungefixtem Kernel. Der Admin betrieb wissentlich ein verwundbares Sytem. Da hing eine kaputte Kiste am Netz. Immernoch fragen? Ja? Sie sind gefeuert. Und sie können sicher sein, nach der Kanone die sich geleistet haben können sie sehr lange nach nem neuen Job oder Kunden suchen.
*Aua*, echt jetzt, das geht doch gar nicht mehr
@fuffy
War nicht persönlich gemeint. Ich krieg da nur die Krise wenn jemand wissentlich ein fehlerhaftes System betreibt und dann rumfenzt und vom eigenen Versagen ablenkt. Da war der Puls leider etwas hoch, sry.
Wenn der Angreifer ein frustrierter Debian-Entwickler gewesen wäre, dem der lokale Login gestattet worden wäre, hätte auch das sicherste Kennwort nichts gebracht, wenn dieser die Lücke im Kernel ausgenutzt hätte.
Das Betriebssystem lief mit ungefixtem Kernel.
Das habe ich schon weiter oben geschrieben.
Der Admin betrieb wissentlich ein verwundbares Sytem. Da hing eine kaputte Kiste am Netz.
Ja, eben. Genau das ist das Problem, nicht unsichere Benutzerkennwörter. Unsichere Benutzerkennwörter dürfen, wenn überhaupt, nur dazu führen, dass der betreffende Account kompromittiert wird. Das System an sich darf dadurch nicht in Leidenschaft gezogen werden. Ein Administrator hat das System vor den eigenen Benutzern zu schützen, sonst könnte man Benutzern gleich sämtlichen Benutzern die UID 0 zuteilen.
Nichts für ungut.
Der Kernel hatte diese Luecke; dass nun wahrscheinlich ein zu schwaches Benutzerpasswort jemandem die Moeglichkeit gegeben hat, diese Luecke auszunutzen, mag zwar stimmen, aber ohne die Luecke im Kernel waere es nie so weit gekommen. Von daher ist auch der Kernel wirklich fehlerbehaftet gewesen, und daran aendert auch nicht die Tatsache, dass der Bug leicht behebbar gewesen ist -- er war da und er wurde genutzt.
Wenn heute um 14:00 Uhr eine Lücke bekannt wird, der Hacker aber bereits Zugang zum System hat, dann hat der Admin keine Chance.
Was sind also die Lösungen ?
Nie wieder Lücken im Kernel und sonst wo ? Unrealistisch
Besseres IDS ? Da ist es schon zu spät, auch wenn es im Nachhinein hilft
RW remount von /usr nur mit über Serielle Konsole erlauben, würde das gehen ?
Root Erlaubniss nur wenn man einen entsprechenden Key hat den man auch remote per ssh verwenden kann ? Würde doch sicher helfen oder ?
Auf jeden Fall ist wohl auf den Debian Servern spätestens ab jetzt eine Überprüfung der Passwörter bei Erstellung und Änderung gefragt. Genauso wie der Abgleich der Prüfsummen aller Dateien in $PATH mit einer externen sicheren readonly Liste.
felix
SE Linux kapselt jeden Prozess (also auch User) in einer eigenen Domäne. Domänentransitionen sind
nur durch _ausdrückliche_ Erlaubnis in der Policy möglich.
Ein User kann sich auf SE Linux-gesicherten Systemen keine root-Rechte erschleichen, da z.B. Buffer Overflows nicht aus ihrer Domäne herauskommen.
Beispiel: Ein Apache, dem über einen Buffer Overflow ein Injection Vector untergejubelt wurde
stürzt zwar ab, da aber der Apache keine Shell starten darf (unter SE Linux darf zunächst einmal
keiner irgendetwas), bleiben Exploits wirkungslos.
Es gibt nur 2 Haken:
1. SE Linux schützt nicht vor schwachem Root-Passwort
2. Die Administration ist eine echte Herkulesaufgabe (extrem komplexes Regelwerk)
Bleibt also nur zu hoffen, dass SE Linux schleunigst in Debian Einzug hält.
Hier ein wenig Lesestoff:
http://www.computerwoche.de/knowledge_center/linux/558221/
http://www.nsa.gov/selinux/
Wer sich beweisen will:
http://www.coker.com.au/selinux/play.html
Und hier Russel Cokers Doku zur Playmachine:
http://www.selinux-symposium.org/2005/presentations/session7/7-1-coker.pdf
Dank und Gruß
Felix
Hmmm ... ich muss gestehen, ich bin mir nicht sicher ;-)
Ob SE Linux hier helfen kann müsste man wissen, wie genau der Dump geschieht. Wenn dies ein Prozess aus dem Userspace übernimmt, sehe ich da gute Chancen. Für den Fall, dass der Kernel selbst das macht habe ich so meine Bedenken.
Ich vermute aber, dass man Cron davor bewahren könnte, die Datei zu starten (denn für sie existiert ja keine Policy-Regel)
Grüße,
filthgrinder
Was den Bug betrifft... -> Mit SuSE wäre das nicht passiert...
Stimmt .... FullAck, mit SuSe kommst du nicht mal ins Netz, geschweige eine ServerInstallation, daher ist
SuSe wirklich das sicherste nach WindowsXP.
Wer mit SuSE schon nicht ins Netz kommt, sollte von den anderen 800 oder mehr Distris doch lieber die Finger lassen.
Hätte es aber nicht für möglich gehalten, dass die sich da die Passwörter so frei auswählen dürfen, dass man sie per Dictionary Attacken rausbekommen kann...
Es ist Sache des Administrators, dafür zu sorgen, dass ein normaler Benutzer (UID > 0) das System nicht lahmlegen kann.
Wenn du zu deinen Benutzern vollstes Vertrauen hättest, könntest du ihnen gleich dein root-Kennwort geben.
Aufgabenstellung: neuer User bekommt Account.
0) Zugang per Passwort auf die Server wird abgestellt
1) User und Admin tauschen ihre GPG-Identitäten untereinander aus
2) User schickt Admin einen seiner öffentlichen SSH-Schlüssel und signiert die dazugehörige Email
3) Admin erzeugt Account und trägt den SSH-Schlüssel vom User in die authorized_keys ein
4) Admin schickt User die Accountdaten in verschlüsselter Email
5) Ein Jahr später muß (meinethalben über einen Emaildienst) ein neuer öffentlicher SSH-Schlüssel übermittelt werden
6) Account wird gesperrt, falls 5) nicht innerhalb eines Monats vor Ablauf des Jahres durchgeführt wird
Sobald Schritt 1 manuell durchgeführt wurde, kann der Rest komplett automatisiert werden und es fliessen keine Passwörter mehr.
lg
Erik
Und trotzdem ist ein Login auf den Servern nur per SSH erlaubt? SSH verschlüsselt die Session auf beiden Seiten, also auch im Land, in dem Verschlüsselung verboten ist (wo eigentlich ausser in Russland und irgendwelchen Diktaturen?). Dann müßte man konsequenterweise auf jegliche Verschlüsselung verzichten und das ist nicht drin.
lg
Erik
Un die USA ist ja wohl *hust* eine demokratie *kotter*
Ach ja, Linux & Co. -- es geht zielstrebig den Bach hinunter, ganz demokratisch.
> Die Lücke betrifft alle Kernel-Versionen von 2.6.13 bis 2.6.16.23 bzw. 2.6.17.3.
Das ist so nur für ungepatchte Kernel richtig.
Die verschiedenen Distributionen, die ältere Kernel einsetzen, haben für diese meist schon lange entsprechend gepatchte Kernelupdates herausgebracht.
...nur um mal ein paar Leute zu beruhigen...