Ist "LD_LIBRARY_PATH" ein Sicherheitsrisiko?


8

Wir kennen die ld.soSuche nach Bibliotheken in Verzeichnissen, die von der Umgebungsvariablen angegeben werden $LD_LIBRARY_PATH, aber normale Benutzer können Folgendes ausführen:

export LD_LIBRARY_PATH=dir1:dir2...

Sie können infizierte Bibliotheken in einem Pfad mit höherer Priorität als die ursprüngliche speichern, sodass diese ld.soanstelle der vertrauenswürdigen Bibliothek in der gefunden wird ld.so.cache.

Ist das ein Risiko?
Wie können wir das Schreiben in diese Umgebungsvariable für normale Benutzer deaktivieren?


Vielen Dank an @Byte Commander für die Bearbeitung. Mein Englisch ist nicht gut :)
Sinoosh

Kein Problem, es ist besser als der Durchschnitt :)
Byte Commander

Antworten:


17

Dies ist überhaupt kein Sicherheitsrisiko, da Sie immer nur Umgebungsvariablen für Ihre aktuelle Umgebung (z. B. aktuelle Bash-Sitzung) und mithilfe des exportBefehls die untergeordneten Umgebungen (von Ihnen gestartete Skripts, Subshells usw.) festlegen können. Es ist unmöglich, eine Umgebungsvariable, die erstellt oder geändert wurde, in die übergeordnete Umgebung zu eskalieren. Dazu gehört natürlich, dass normale Benutzer keine systemweiten Änderungen vornehmen können.

Die einzige Umgebung, die beim Ausführen betroffen wäre, export LD_LIBRARY_PATH=...ist Ihre aktuelle Shell und alle Subshells davon, die Sie möglicherweise später erzeugen. Angenommen, Sie ändern den Suchpfad so, dass infizierte Bibliotheken am Anfang eingeschlossen werden, dh mit der höchsten Priorität. Dann führen Sie eine ausführbare Datei aus, die eine der infizierten Bibliotheken lädt, ohne es zu wissen. Was passiert jetzt?

Sie haben bösartigen Code (aus der infizierten Bibliothek), der unter Ihrem eigenen Benutzerkonto mit regulären Nicht-Administratorrechten ausgeführt wird. Das mag schlecht klingen, aber eigentlich ... na und? Es wird mit regulären Benutzerrechten ausgeführt, was wiederum bedeutet, dass es nicht das gesamte System betreffen kann. Übrigens wäre es viel einfacher gewesen, eine ausführbare Datei mit demselben Schadcode direkt auszuführen, als den Pfad für die Bibliothekssuche zu ändern und darauf zu warten, dass eine normale ausführbare Datei sie lädt.

Schlussfolgerung: Ein normaler Benutzer kann nur seinen eigenen Bibliotheks-Suchpfad ändern. Dies bedeutet, dass er diese Bibliotheken auch nur unter seinem regulären Benutzerkonto mit regulären nicht systemweiten Berechtigungen selbst laden kann. Es macht jedoch keinen Unterschied, ob sie das Laden einer infizierten Bibliothek erzwingen oder eine infizierte ausführbare Datei direkt ausführen. Sie würden absolut nichts gewinnen, wenn diese Umgebungsvariable nicht von Benutzern überschrieben werden könnte.

PS: Es gibt auch ausführbare Dateien , die die haben setuid oder setgid - Flag gesetzt, das heißt , sie werden nicht als Benutzer / Gruppe des einen Lauf, der sie läuft, aber von dem, der besitzt sie. Zum Beispiel gehört die sudoausführbare Datei root und hat das Flag setuid gesetzt, was bedeutet, dass sie bei der Ausführung immer als root ausgeführt wird. Aus Sicherheitsgründen wird die $LD_LIBRARY_PATHVariable von ausführbaren Dateien ignoriert, wobei eines der Flags setuid / setgid gesetzt ist, um sicherzustellen, dass der reguläre Benutzer keine ausführbare Datei mit Root-Rechten zum Laden beliebiger Bibliotheken ausführen kann.
(Danke an @Rinzwind für den Hinweis!)


Vielen Dank ! Ich lese gerade ein Buch, in dem es heißt: "LD_LIBRARY_PATH wird als Sicherheitsrisiko angesehen, da es möglicherweise nicht autorisierten Programmen den versehentlichen Zugriff auf Systembibliotheken ermöglicht oder auf andere Weise Systembibliothekspfade nicht autorisierten Benutzern zugänglich macht." was das bedeautet?
Sinoosh

1
@Sinoosh Ich kann mir keinen Grund vorstellen, warum es ein Sicherheitsproblem sein sollte, wenn eine nicht vertrauenswürdige Anwendung den Speicherort meiner Systembibliotheken kennt. Wenn alles richtig konfiguriert ist und Sie nicht mit Berechtigungen herumgespielt haben, sollten sie Eigentum von root sein und von niemand anderem beschreibbar sein. Dies bedeutet, dass kein Risiko besteht, dass sie in irgendeiner Weise infiziert oder geändert werden (es sei denn, Sie führen die nicht vertrauenswürdige Anwendung als root aus , aber Sie werden das nicht tun, richtig?)
Byte Commander


@ Byte Commander, ich bin mit Ihnen nicht mit Autor einverstanden :)
Sinoosh

Diese Antwort ist nicht ganz richtig. LD_LIBRARY_PATHDies ist natürlich ein Sicherheitsproblem, wenn Sie zuerst eine schädliche Bibliothek laden und das Verhalten einer Binärdatei ändern.
Heemayl
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.