Sichere Zugriff auf Dateien in einem Verzeichnis durch eine Umgebungsvariable identifiziert?

Question

Kann mir jemand Punkt zu einem gewissen Code, der mit der Sicherheit von Dateien Zugriff über einen Pfad (teilweise) angegeben befasst sich durch eine Umgebungsvariable, die speziell für Unix und seine Varianten, aber Windows-Lösungen sind ebenfalls von Interesse?

Dies ist eine große lange Frage - ich bin nicht sicher, wie gut es das SO Paradigma paßt

.

Betrachten Sie dieses Szenario:

Hintergrund:

• PQR Software-Paket kann von Benutzern ausgewählt an einem Ort installiert werden.
• Die Umgebungsvariable $ PQRHOME wird verwendet, um das Installationsverzeichnis zu identifizieren.
• Standardmäßig werden alle Programme und Dateien unter $ PQRHOME gehören zu einer speziellen Gruppe, pqrgrp.
• Ebenso sind alle Programme und Dateien unter $ PQRHOME gehören entweder zu einem speziellen Benutzer, pqrusr oder an Benutzer root (und das sind SUID root-Programme).
• Einige Programme sind SUID pqrusr; ein paar mehr Programme sind SGID pqrgrp.
• sind die meisten Verzeichnisse von pqrusr Eigentum und gehören zu pqrgrp; einige können zu anderen Gruppen gehören, und die Mitglieder dieser Gruppen erwerben zusätzliche Privilegien mit der Software.
• Viele der privilegierten ausführbaren Dateien müssen von Personen ausgeführt werden, die nicht Mitglieder pqrgrp sind; die Programme zu bestätigen, dass der Benutzer es von obskuren Regeln zu laufen erlaubt ist, die nicht direkt auf diese Frage betreffen.
• Nach dem Start haben einige der privilegierten Programme ihre erhöhte Privilegien behalten, weil sie lang andauernde Dämonen sind, die im Auftrag vieler Anwender über ihre Lebensdauer wirken können.
• Die Programme sind nicht zu ändern Verzeichnis $ PQRHOME für eine Vielzahl von obskuren Gründen zugelassen.

Aktuelle Prüfung:

• Die Programme zur Zeit prüfen, ob $ PQRHOME und Schlüssel Verzeichnisse darunter sind ‚sicher‘ (im Besitz von pqrusr, pqrgrp gehört, haben nicht öffentlichen Schreibzugriff).
• Danach Programme Zugriff auf Dateien unter $ PQRHOME über den vollen Wert der Umgebungsvariable.
• Insbesondere die G11N und L10N wird durch den Zugriff auf Dateien in ‚sichere‘ Verzeichnisse erreicht und Formatstrings für printf Lesen () usw. aus den Dateien in diesen Verzeichnissen, den vollständigen Pfad mit abgeleitet von $ PQRHOME zuzüglich eines bekannten Unter -Struktur (zum Beispiel $ PQRHOME / g11n / en_us / messages.l10n).

Angenommen

, dass der 'als installierte' Wert von $ PQRHOME ist / opt / PQR.

Bekannte Angriff:

• Attacker setzt PQRHOME = / home / Angreifer / PQR.
• Dies ist eigentlich ein symbolischer Link auf / opt / PQR, so dass, wenn einer der PQR Programme, nennt es PQR-Opfer, überprüft das Verzeichnis, es richtige Berechtigungen hat.
• Unmittelbar nach der Sicherheitsüberprüfung erfolgreich abgeschlossen ist, ändert sich der Angreifer den Symlink so dass es auf / home / Angreifer / Schein-pqr, die deutlich unter der Angreifer Kontrolle ist.
• Dire Dinge passieren, wenn das PQR-Opfer nun eine Datei unter dem vermeintlich sicheren Verzeichnis zugreift.

Da PQR verhält sich zur Zeit, wie beschrieben, und ist ein großes Paket (mehrere Millionen Zeilen Code, mehr als ein Jahrzehnt auf eine Vielzahl von Kodierungsstandards entwickelt über, die häufig ignoriert wurden, sowieso), welche Techniken würden Sie das Problem zu beheben verwenden?

Bekannte Optionen sind:

1. Ändern Sie alle Formatierungen ruft Funktion zu verwenden, die aktuellen Argumente gegen die Format-Strings überprüft, mit einem zusätzlichen Argument unter Angabe der tatsächlichen Typen der Funktion übergeben. (Dies ist schwierig und potentiell fehleranfällig, weil die schiere Anzahl der Formatoperationen geändert werden -. Aber wenn die Prüffunktion selbst Sound ist, funktioniert gut)
2. Stellen Sie den direkten Weg zu PQRHOME und validieren es für die Sicherheit (Details siehe unten) und weigerte sich zu starten, wenn es nicht sicher ist, und danach den direkten Weg und nicht über den Wert von $ PQRHOME (wenn sie sich unterscheiden). (Dies erfordert, dass alle Dateioperationen, den $ PQRHOME verwenden nicht den Wert von getenv () zu verwenden, aber der abgebildeten Pfad. Zum Beispiel würde dies erfordert dieSoftware, dass / home / Angreifer zu etablieren / PQR ist ein symbolischer Link auf / opt / PQR, dass der Pfad zu / opt / PQR ist sicher, und danach, wenn eine Datei als $ PQRHOME / some / Sache verwiesen wird, der Name verwendet würde sein / opt / PQR / some / Sache und nicht / home / Angreifer / PQR / some / Sache. Dies ist eine große Codebasis -. Nicht trivial zu beheben)
3. Stellen Sie sicher, dass alle Verzeichnisse auf $ PQRHOME, auch durch Symlinks Tracking sicher sind (Details siehe unten, wieder), und die Software weigert zu starten, wenn alles unsicher ist.
4. Hard-Code der Pfad zu der Software installieren Lage. (Dies wird nicht PQR arbeiten,... Es macht das Testen der Hölle, wenn nichts anderes Für den Anwender bedeutet dies können sie haben aber eine Version installiert und Upgrades usw. erfordert parallel laufende Dies funktioniert nicht für PQR)

Vorgeschlagene Kriterien für die sicheren Pfade:

• Für jedes Verzeichnis, muss der Eigentümer vertrauen. ( Begründung:. Eigentümer kann jederzeit Berechtigungen ändern, so der Inhaber vertraut werden müssen keine Änderungen zufällig zu machen, die die Sicherheit der Software brechen )
• Für jedes Verzeichnis, muss die Gruppe entweder keine Schreibrechte besitzen (so die Mitglieder der Gruppe nicht den Verzeichnisinhalt ändern kann) oder die Gruppe vertraut werden muss. ( Begründung:., Wenn die Gruppenmitglieder das Verzeichnis ändern können, dann können sie die Sicherheit der Software brechen, also entweder sie müssen es ändern nicht in der Lage, oder sie müssen vertraut werden nicht verändert es )
• Für jedes Verzeichnis, ‚andere‘ muss auf dem Verzeichnis keine Schreibberechtigung haben.
• standardmäßig der Benutzer root, ist, sys und pqrusr vertraut werden kann (wo ist und sys existieren).
• Standardmäßig wird die Gruppe mit GID = 0 (verschiedentlich als Wurzel, Rad oder ein System bekannt), ist, sys und pqrgrp vertraut werden kann. Zusätzlich ist die Gruppe, die das Root-Verzeichnis besitzt (die auf MacOS X Server-Betreiber genannt) vertraut werden kann.

Die POSIX-Funktion realpath() stellt einen Mapping-Dienst, wird Karte / home / Angreifer / PQR zu / opt / PQR; es nicht die Sicherheitsüberprüfung tun, aber das muss nur auf dem aufgelösten Pfad erfolgen.

So, mit allem, als Hintergrund, ist es eine bekannte Software, die durch vage verwandten Verrenkungen geht seine Sicherheit zu gewährleisten? Wird diese übermäßig paranoid? (Wenn ja, warum - und sind Sie wirklich sicher?)

Editiert:

Danke für die verschiedenen Kommentare.

@ S.Lott: Der Angriff (in der Frage umrandet) bedeutet, dass mindestens ein setuid root Programm gemacht werden kann, eine Format-String des (unprivilegierten) des Benutzers Wahl zu verwenden, und das Programm zumindest zum Absturz bringen kann und daher die meisten wahrscheinlich kann ein root-Shell erwerben. Es erfordert lokalen Shell-Zugang, zum Glück; es ist kein entfernter Angriff. Es erfordert eine nicht zu vernachlässigende Menge an Wissen um dorthin zu gelangen, aber ich halte es für unklug, anzunehmen, dass die Know-how nicht ist ‚da draußen‘.

Also, was ich beschreibe, ist eine ‚Format-String-Schwachstelle‘ und der bekannte Angriffspfad beinhaltet das Programm vorgetäuscht, so dass, obwohl es es denkt, sichere Nachrichtendateien zugreift, geht es tatsächlich und verwendet die Nachrichtendateien (die enthalten Format-Strings), die unter der Kontrolle des Benutzers sind, nicht unter der Kontrolle der Software.

Answer 1

Option 2 funktioniert, wenn Sie einen neuen Wert für $PQRHOME schreiben, nachdem seinen wahren Weg zu lösen und ihre Sicherheit überprüfen. Auf diese Weise nur sehr wenig von Code geändert werden muss danach.

Soweit setuid- Privilegien zu halten, würde es helfen, wenn Sie irgendeine Art von Privileg Trennung zu tun, so dass die Vorgänge Eingabe von den realen Benutzern und die im Rahmen der realen uid laufen. Der privilegierte Prozess und der Echt uid Prozess dann mit einem socketpair oder etwas ähnlichem sprechen.

Answer 2

Nun, es Sounds paranoid, aber wenn Sie es oder nicht, hängt davon ab, welches System (n) Ihre Anwendung läuft auf und die Schäden kann ein Angreifer tun.

Also, wenn Ihr totzukriegen möglicherweise feindlich ist und wenn der Schaden möglicherweise sehr hoch ist, würde ich für die Option 4, jedoch modifiziert gehen Sie wie folgt vor seine Nachteile zu entfernen.

Lassen Sie mich zwei relevante Dinge zitieren:

1)

  

Die Programme zur Zeit prüfen, ob $ PQRHOME und Schlüsselverzeichnisse   darunter ‚sicher‘ (im Besitz von pqrusr sind,   pqrgrp gehören, nicht öffentlich haben   Schreibzugriff).

2)

  

Danach Programme zugreifen Dateien unter $ PQRHOME über die volle   Wert der Umgebungsvariablen.

Sie brauchen nicht wirklich schwer Code für den vollständigen Pfad, können Sie hart Code nur den relativen Pfad aus dem „Programm“ Sie in 1 erwähnt) auf den Weg in 2 erwähnt), wo die Dateien sind.

Ausgabe an Kontrolle:

a) müssen Sie sicher sein, dass es nichts „Angreifer zugänglich“ ist (zum Beispiel in der Bezeichnung des Symlinks) zwischen der Pfad der ausführbaren Datei und die Dateien Pfad

b) Sie müssen sicher sein, dass die ausführbare Datei seinen eigenen Weg überprüfen auf zuverlässige Art und Weise, aber das sollte kein Problem in allen Unix'es sein Ich weiß, (aber ich weiß nicht, alle ‚em und I don‘ t wissen, Fenster überhaupt).

---

EDITED nach dem 3. Kommentar:

Wenn Ihr OS Support / proc, die syslink / proc / $ {pid} / exe der beste Weg ist, b zu lösen)

---

EDITED nach dem Schlafen auf sie:

Ist die Installation ein „sicherer“ Prozess? Wenn ja, könnten Sie (bei der Installation) einen Wrapper-Skript erstellen. Dieses Skript sollte ausführbar sein, aber nicht beschreibbar (und möglicherweise weder lesbar). Es würde die $ PQRHOME env var auf den „sicheren“ Wert gesetzt und dann aktuelle Programm aufrufen (es könnte schließlich tun andere nützliche Dinge auch). Da in UNIX die env vars eines laufenden Prozesses nicht durch etwas anderes als den laufenden Prozess geändert werden, können Sie sicher sind (natürlich die env vars können von der Mutter geändert werden vor der Prozess beginnt). Ich weiß nicht, ob dieser Ansatz in Windows funktioniert, though.