Zusammenfassung
- COPS machte bekannte Unix-Probleme — schwache Passwörter, zu offene Rechte und exponierte Startdateien — auf einem lokalen Host wiederholt prüfbar.
- Die konfigurierbaren Programme meldeten mögliche Schwächen, behoben sie aber nicht. Die meisten brauchten kein root; die umfassendere SUID-Suche lief getrennt und benötigte Privilegien.
- Ein unauffälliger Bericht beschreibt die eingerichteten Prüfungen und ihre Reichweite zum Laufzeitpunkt. Er bescheinigt weder vollständige Sicherheit noch einen unveränderten Host.
Die alltäglichen Fehler erneut finden
Der Aufsatz von 1990 beginnt mit einer nüchternen Beobachtung: In der Unix-Sicherheitsliteratur tauchten dieselben Probleme immer wieder auf. SUID-Programme, zu großzügige Dateirechte und schwache Passwörter ließen sich oft leicht beheben, sobald man sie gefunden hatte. Schwieriger war die regelmäßige Suche in Installationen, die sich veränderten. Farmer und Spafford wollten diese Kontrolle wiederholbar machen.
COPS steht für „Computerized Oracle and Password System“, war aber kein Netzwerkscanner. Ein übergeordnetes Shell-Skript sammelte die Ergebnisse von etwa einem Dutzend Teilprogrammen und schickte sie an den lokalen Administrator oder schrieb sie in eine Datei. Die meisten Komponenten nutzten Bourne-Shell und gängige Unix-Befehle; kleine C-Programme ergänzten sie bei Bedarf. Für einzelne Standorte ließ sich das Werkzeug anpassen oder erweitern.
Die Prüfungen betrafen klar benannte Verwaltungsflächen: konfigurierte Dateien und Verzeichnisse, die alle beschreiben konnten; Passwörter gleich dem Benutzernamen oder aus häufigen Wörtern; Fehler in Konto- und Gruppendateien; beschreibbare Dateien, die cron- oder Startskripte ausführten; Rechte ausgewählter Geräte; Home-Verzeichnisse und Initialisierungsdateien; umask und Suchpfade in Root-Startdateien. suidchk verglich den aktuellen Bestand der SUID-Dateien mit einem früheren Lauf. Kuang prüfte regelbasiert, ob ein Benutzer nach diesen Regeln zur Kompromittierung des Zielkontos gelangen konnte.
Darin lag der Nutzen: Eine festgelegte Reihe lokaler Prüfungen ließ sich günstiger wiederholen. COPS deckte nicht jeden denkbaren Fehler ab und entschied auch nicht, ob jedes Recht gegen die Richtlinie eines Standorts verstieß.
Der Prüfer nahm keine Änderungen vor
Die Autoren wollten, dass COPS meldet, nicht den Host verändert. Zwei Installationen mit ähnlicher Hardware und Unix-Version können unterschiedliche Arbeit, Daten und Zugriffsbedürfnisse haben. Eine vertretbare Einstellung am einen Standort kann am anderen untragbar sein. Eine automatische Korrektur hätte eine technische Feststellung in eine Richtlinienentscheidung verwandelt, für die dem Programm der Kontext fehlte.
Auch die Privilegien spiegelten diese Zurückhaltung wider. Laut Aufsatz sollten die Werkzeuge außer der SUID-Suche nicht als root laufen. Diese Suche wurde oft getrennt gestartet, weil sie länger dauern und auch für normale Konten unzugängliche Verzeichnisse durchsuchen konnte. So brauchten Routineprüfungen weniger Rechte; zugleich hing die Reichweite des Berichts davon ab, wie jede Komponente ausgeführt wurde.
Der Aufsatz empfiehlt regelmäßige Läufe mit at oder cron, denn ein heute fehlender Befund kann später entstehen. Ein Zeitplan sorgt nicht für Vollständigkeit. Ein veränderter Prüfer oder Pfadbestand kann irreführen; Angreifer könnten Berichte lesen oder das Werkzeug verändern; wiederholt unauffällige Ergebnisse können Selbstzufriedenheit erzeugen. Änderungen am Systembetrieb können zudem Schwächen schaffen, die die bisherigen Prüfungen nicht erfassen.
Was die Belege hergeben
Farmer und Spafford erhielten Rückmeldungen aus Wissenschaft, Verwaltung und Wirtschaft. Bei mehr als der Hälfte der getesteten oder in Rückmeldungen beschriebenen Systeme fanden sich laut Aufsatz Probleme, die root gefährden konnten. Die Autoren schränkten ein, dass sich diese begrenzte Beobachtung nicht sicher auf eine größere Grundgesamtheit übertragen ließ. Sie ist keine Verbreitungsstatistik für Unix.
COPS und Farmers späteres SATAN untersuchten unterschiedliche Oberflächen: lokale Konten, Dateien, Rechte und Startkonfigurationen bei COPS; Netzdienste und die von anderen Hosts sichtbare Angriffsfläche bei SATAN. Der gemeinsame Autor macht ihre Berichte nicht austauschbar.
Heng Lus Note 65 dient nur als redaktionelle Perspektive: Aussagen über ein laufendes System sollten nicht über das hinausgehen, was ausgeführte Prüfungen beobachtet haben. Bei COPS heißt das, nach Prüfungen, Rechten, Pfaden und Zeitpunkt zu fragen. Automatisierung macht eine Prüfliste wiederholbar; Umfang, Vertraulichkeit, Interpretation und Korrektur bleiben Verantwortung des Betreibers.
Quellen
- Farmer und Spafford, „The COPS Security Checker System“ (Originalaufsatz)
- USENIX-Bibliografie: Tagungsband Sommer 1990
- Eugene H. Spafford, CERIAS-Rückblick auf COPS
- Purdue CERIAS, Spaffords „Firsts“
- Nur redaktionelle Perspektive: Heng Lu, Note 65, „Running-Code Primacy“
- Nur als Identitätsreferenz: öffentliches Dan-Farmer-Porträt bei Wikimedia Commons
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
