Frage:
Was sind die potenziellen Schwachstellen, die es Nicht-Root-Benutzern ermöglichen, apt-get auszuführen?
kzl
2020-06-12 04:30:51 UTC
view on stackexchange narkive permalink

Es gibt zwei Möglichkeiten, wie ich mir das vorstellen kann:

  1. Auf einem System mit sudo durch Ändern von / etc / sudoers .

  2. Auf einem System ohne sudo (z. B. einer Docker-Umgebung) schreiben Sie ein Programm ähnlich dem folgenden und stellen die Setuid ein Bit mit chmod u + s . apt-get prüft die echte UID, daher ist ein Aufruf von setuid erforderlich.

    3. ol> 
      ... int main (int argc, char ** argv) {char * envp [] = {...}; setuid (0); execve ("/ usr / bin / apt-get", argv, envp); return 1;}

    Ich habe zwei Fragen:

    1. Was sind die potenziellen Schwachstellen, wenn Nicht-Root-Benutzer apt-get ?
    2. Mein Ziel ist es, Benutzern das Installieren / Entfernen / Aktualisieren von Paketen zu ermöglichen, da apt-get in einem benutzerdefinierten Nicht-System-Refroot lebt und von einem benutzerdefinierten installiert wird kuratiertes apt Repository. Gibt es sicherere Möglichkeiten, Nicht-Root-Benutzern zu ermöglichen, apt-get auf einem System ohne sudo ?
      3. ol> auszuführen
Dieser Blog-Beitrag fällt mir ein: https://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html Insbesondere Apt ist dort nicht aufgeführt, aber ich würde es überhaupt nicht erwarten, wenn es so wäreirgendwie Befehlsausführung erlaubt.Vielleicht gibt es durch die Angabe eines Repositorys in der Befehlszeile (das unter der Kontrolle des Angreifers steht) ein Flag für eine lokale Deb-Datei ... und all dies ignoriert, dass man Systempakete entfernen oder Pakete auf dem neuesten Stand halten könntedurch Verwalten einer Sperrdatei.
Ein Vorschlag für einen sichereren Weg hängt davon ab, was Sie tun möchten.Müssen Leute Pakete installieren?Nur Pakete aktualisieren?Oder möchten Sie nur einen Audit-Trail?Was ist das Ziel hier?
Danke für das Engagement!Ziel ist es, Benutzern das Installieren / Entfernen / Aktualisieren von Paketen zu ermöglichen.
https://www.cyberciti.biz/faq/debian-ubuntu-linux-hook-a-script-command-to-apt-get-upgrade-command/ Dies ist eine Methode, die die Ausführung von beliebigem Code für apt-get ermöglicht, für deren Implementierung jedoch Root-Berechtigungen erforderlich sind.Ich konnte keine anderen finden.
Wenn Benutzer Pakete entfernen müssen müssen, können sie das System jederzeit beenden, indem sie Systempakete entfernen.Ein sicherer Weg könnte darin bestehen, ein Skript zu schreiben, das einen Paketnamen akzeptiert, ihn filtert und maskiert und apt install / upgrade aufruft.Zum Entfernen könnte dieses Skript möglicherweise die vom Benutzer installierten Pakete verfolgen und nur das Entfernen dieser Pakete zulassen?Es ist nicht trivial, sicherzustellen, dass solche benutzerdefinierten Elemente sicher sind: Wenn dies wichtig ist, möchten Sie möglicherweise jemanden zum Testen der Lösung veranlassen.Oder vielleicht gibt es da draußen Lösungen, von denen ich noch nichts gehört habe (ich habe mich nicht geduckt / gegoogelt).
Ich habe gerade in der Frage klargestellt, dass apt-get in einer benutzerdefinierten Refroot installiert ist!Systempakete sind nicht gefährdet.Ich stimme zu, es ist nicht trivial.Gleichzeitig habe ich keine Schwachstellen gefunden oder daran gedacht, die sich daraus ergeben könnten. Deshalb wollte ich hier fragen, ob jemand eine Antwort hat.
Benutzer sollten mit ziemlicher Sicherheit Container erstellen, anstatt ... was auch immer dies ist.Schauen Sie sich wurzellose Containerlösungen wie Podman.
Während die negativen Antworten alle gut und richtig sind, kann das, was OP will, im Prinzip sicher durchgeführt werden, indem alles außer der Anforderung eines neuen Pakets im bereits vorhandenen vertrauenswürdigen Repo-Set verboten wird.Das birgt immer noch Bedrohungen wie das Starten eines unsicheren Daemons mit Berechtigungen, aber es ist eher vernünftig, als willkürliche "apt-get" -Befehle zuzulassen.
@MichaelHampton Vielen Dank für Ihren Vorschlag.Um meinen Anwendungsfall zu verdeutlichen, habe ich tatsächlich gefragt, ob Benutzer apt-get in einer Docker-Umgebung verwenden dürfen.Jeder Benutzer hat seinen eigenen Docker-Container, und obwohl ich sicherstellen möchte, dass keine beliebigen Befehle als Root ausgeführt werden können, möchte ich ihm auch erlauben, Pakete aus einem benutzerdefinierten Repository zu installieren.
@R..GitHubSTOPHELPINGICE Vielen Dank für Ihren Vorschlag!Könnten Sie bitte klarstellen, was Sie damit meinen, dass ein unsicherer Daemon mit Berechtigungen gestartet wird?
[aptdaemon] (https://launchpad.net/aptdaemon) in Kombination mit polkit ermöglicht es, Paketlisten und bereits vorhandene Pakete auf Debian / Ubuntu zu aktualisieren, ohne root zu sein.
@kzl: Sofern sich nichts geändert hat (zugegebenermaßen ist es lange her, dass ich Debian-basierte Dists außer in Containern berührt habe), stellen Pakete, die Daemons bereitstellen, Init-Dateien (Systemd Service oder Dbus-Aktivierung oder was auch immer) bereit, die dazu führen, dass sie automatisch ausgeführt werden.Wenn Sie also einen obskuren Junk installieren können, können Sie ihn als Angriffsfläche verwenden.Wenn es als root ausgeführt wird, können Sie root werden.
Selbst wenn Sie es schaffen, alle Probleme im Zusammenhang mit apt zu schließen, müssen Sie dasselbe für dpkg tun.Und für Leute, die einen Pfad festlegen, der auf einen Symlink zu einer Shell verweist.
@R..GitHubSTOPHELPINGICE Was OP will, kann sowohl sicher als auch einfach mit nix erledigt werden.nix ist ein Paketmanager, der neben apt-get arbeiten kann.Es ist interessant, wie nix so aufgebaut ist, dass es keine Sicherheitsprobleme gibt, die allen Benutzern uneingeschränkten Zugriff auf nix ermöglichen.Es ist einfach, nix unter Ubuntu https://nixos.org/download.html zu installieren
Fünf antworten:
Cyclic3
2020-06-12 20:48:42 UTC
view on stackexchange narkive permalink 
  apt-get update -o APT :: Update :: Pre-Invoke :: = / bin / sh

Von GTFOBins

Dies gibt Ihnen eine Root-Shell auf dem System. Kein Erstellen von Paketen und Hinzufügen gefälschter Repos; Dadurch erhält der Benutzer, der diesen Befehl ausführt, einfachen und einfachen Zugriff auf root.

Als Antwort auf Ihre Frage geben Sie jedem Benutzer, der Zugriff auf diese Binärdatei hat, effektiv root. Wenn Sie dazu bereit sind, können Sie ihnen auch einfach den Sudo-Zugriff oder das Root-Passwort geben.

Dies sollte wirklich eine akzeptierte Antwort sein, IMO;Es ist eine viel elegantere Lösung, die die Frage "Was kann ein Benutzer mit" apt "tun?" klarer beantwortet. Sie benötigen nicht einmal eine Quellenliste, eine Paketdatei, einen Internetzugang oder irgendetwas anderes ... es ist nur sofortlässt dich in eine Muschel fallen.
@CBHacking Ich habe es gemäß Ihrem Vorschlag in eine akzeptierte Antwort geändert - danke.Dies ist wahrscheinlich die Antwort, an der die meisten Menschen interessiert wären, obwohl sie nicht darauf eingeht, wie dieses Risiko gemindert werden kann, wie es die Antwort von Arminius unten tut.https://security.stackexchange.com/a/233162/236489
@CBHacking Vielen Dank!Mein Exploit ist meiner Erfahrung nach in der realen Welt besser anwendbar: Ich habe einige Management-Panels gesehen, mit denen Benutzer Repos ändern und Pakete installieren können, ohne den eigentlichen Befehl "apt-get" selbst verfügbar zu machen.
Es ist das Dümmste, was man tun kann, wenn man ihnen eine Root-Shell (oder einen Systemzugriff auf apt-get) zur Verfügung stellt.Wenn es sich um ein Klassenzimmer oder eine ähnliche Umgebung handelt, können Sie sicher sein, dass mindestens ein Benutzer in der Lage ist, diese zu verwenden.Was genau ist der Sinn eines Sicherheitssystems, nur um seine Autorität zu untergraben?Wenn Sie einen dieser beiden Wege gehen, können Sie sicher sein, dass gestörte Schüler dies als Folgendes verstehen: Die Herausforderung ist eröffnet.Eine solche Konfiguration sollte besser in einem isolierten Netzwerksegment aufbewahrt werden.
CBHacking
2020-06-12 10:25:18 UTC
view on stackexchange narkive permalink

Sie sagen, Sie verwenden ein "benutzerdefiniertes kuratiertes Apt-Repository", aber es gibt keine Möglichkeit, dies durchzusetzen. Jeder Benutzer, der apt aufrufen kann, kann seine eigene Quellliste angeben, z. B. apt install root-backdoor -o Dir :: Etc :: Sourcelist = ~ / apt / my-own-sources. Liste . Dies kann auch für alle anderen Konfigurationseinstellungen durchgeführt werden. Dies bedeutet, dass Sie auch beliebige Dateien mit dem von Ihnen ausgewählten Inhalt überschreiben können (z. B. indem Sie das Cache-Verzeichnis für abgerufene Pakete festlegen).

Pakete können (und häufig) während der Installation beliebige Befehle ausführen. Da der Angreifer den Sourcelist kontrollieren kann, kann er schädliche Pakete erstellen, die entweder nicht privilegierten Benutzern eine privilegierte Hintertür geben oder einfach (als Root) jeden Befehl ausführen, den der Angreifer im Rahmen des "Installations" -Prozesses wünscht.

apt ist absolut kein sicheres Programm, mit dem Personen (mit Root-Rechten) ausgeführt werden können, wenn Sie verhindern möchten, dass sie beliebigen Code mit Root-Rechten ausführen.

BEARBEITEN: Ich möchte aufrufen Beachten Sie diese Antwort als einen viel saubereren Weg, um eine willkürliche Ausführung (als Root) aus apt zu erhalten.

Danke für die Antwort!Ich schätze Ihre Einsicht.Es würde ausreichen, Benutzer daran zu hindern, ihre eigenen Sourcelisten anzugeben (z. B. indem sie einen Wrapper erstellen, der speziell "apt-get install - " mit Root-Rechten aufruft), um zu verhindern, dass Benutzer beliebige Pakete installieren (und somit die Ausführung von willkürlichem Code als Root verhindern))?
@kzl: Sie müssen keinen "Wrapper" erstellen, "sudoers (5)" unterstützt solche Dinge bereits von Haus aus.Ich kann dies jedoch nicht empfehlen, da der Benutzer mit "apt-get" die Version eines Pakets angeben kann, sodass ein Angreifer ein Paket herabstufen kann, um eine Sicherheitslücke zu aktivieren.
Beachten Sie, dass Sie seit apt ~ 1.2 Pakete direkt installieren können, ohne auf ein Repository zu verweisen, indem Sie `. /` Verwenden, um auf eine Deb-Datei zu verweisen.
@Kevin Danke für die Antwort.Die Einschränkungen, die ich oben aufgeführt habe, waren 1) kein Sudo 2) benutzerdefiniertes Refroot (Nicht-System-Apt-Get) und 3) benutzerdefiniertes kuratiertes Apt-Repository.Die Antwort von Armenius unten, die eine Whitelist vorschlägt, befasst sich mit dieser Frage.https://security.stackexchange.com/a/233162/236489
Arminius
2020-06-12 21:45:59 UTC
view on stackexchange narkive permalink

Würde es ausreichen, zu verhindern, dass Benutzer ihre eigenen Sourcelists angeben (z. B. indem ein Wrapper erstellt wird, der speziell apt-get install - <packages> mit Root-Rechten aufruft), um zu verhindern, dass Benutzer beliebige Pakete installieren (und somit die Ausführung von willkürlichem Code als Root verhindern)?

Nein, apt-get kann auch Pakete von Pfaden abrufen. Ein Angreifer könnte ein bösartiges .deb -Paket erstellen, das / etc / <something> für den Root-Zugriff bei der Installation über z. apt-get install - /path/to/foo.deb .

Möglicherweise können Sie es sicher funktionieren lassen, wenn Ihr benutzerdefiniertes Wrapper-Skript nur akzeptiert, was auf einer Whitelist von steht Paketnamen, und wenn Sie garantieren können, dass die Pakete nur von Ihrer Quellenliste übernommen werden - und niemals über benutzerdefinierte Konfigurationen, Umgebungsvariablen usw. bereitgestellt werden können.

Danke, das ist mir auch sehr hilfreich.Ich wünschte, ich könnte mehrere Antworten akzeptieren.
Pedro
2020-06-12 19:20:30 UTC
view on stackexchange narkive permalink
  1. Was sind die potenziellen Schwachstellen, die es Nicht-Root-Benutzern ermöglichen, apt-get auszuführen?
    2. ol>

Vollständiger Systemkompromiss; Anhaltende Eskalation von Berechtigungen durch den Benutzer, der apt-get to root ausführen darf.

  1. Mein Ziel ist es, Benutzern das Installieren / Entfernen / Aktualisieren von Paketen zu ermöglichen, vorausgesetzt, apt -get lebt in einem benutzerdefinierten Nicht-System-Refroot und wird von einem benutzerdefinierten kuratierten Apt-Repository installiert. Gibt es sicherere Möglichkeiten, Nicht-Root-Benutzern das Ausführen von apt-get auf einem System ohne sudo zu ermöglichen?
    2. ol>

Wie hier erläutert, können Sie keine Garantie übernehmen dies.

Natürlich kann man dies garantieren, ohne das Sicherheitssystem zu untergraben.
Martin Zeitler
2020-06-15 19:17:50 UTC
view on stackexchange narkive permalink

Ich bin mit den Antworten bisher überhaupt nicht einverstanden, deshalb habe ich eine andere Perspektive hinzugefügt. Mein Lösungsansatz basiert grob auf einem der Kommentare von @ Cyclic3, wird jedoch nach Bedarf geändert.

Der tatsächliche Angriffsvektor:

Wenn bereits eine root shell, warum die Nutzdaten per Paketmanager liefern? apt-get ist nicht das Hauptproblem (da es nicht unbedingt erforderlich ist, Software zu installieren), aber eine unangemessene Softwarebereitstellung durch nicht autorisierte Benutzer, die besser die Installation der Pakete für sie anfordern sollte. Wenn Sie sie mit einem root -Konto im Internet surfen lassen, wäre dies aus Sicherheitsgründen ungefähr dieselbe Idiotie.

Nebenbei bemerkt, unabhängig von apt -get , sie könnten immer wget einen 0-Tage-Exploit ausführen, der eine Eskalation von Berechtigungen durchführt. Dies würde erfordern, dass White-Listing-Ziele in der Firewall verhindert werden, was die Benutzer im Allgemeinen nicht amüsiert, da hierdurch die gesamte zufällige Internetnutzung (die auch berufsbezogene Webrecherchen umfassen kann) abgeschaltet wird. Dieser Aspekt wird häufig völlig ignoriert.

Eine einfache Self-Service-Lösung:

Da niemand den Server-Serf spielen möchte ... warum nicht eine einfache Web-Benutzeroberfläche schreiben? , welche können sie die Pakete auswählen und sie dann auf dem Computer bereitstellen, von dem sie angefordert haben? Dann einfach ssh in und apt-get ausführen. Dies ist eine Methode der weißen Auflistung (ich kenne yum nur im Detail, die die schwarze Auflistung unterstützt, aber keine weiße Auflistung). Im Allgemeinen ist dies ein sehr einfacher Weg, um nahezu kein Risiko zu gewährleisten, da die root -Shell & apt-get install außerhalb ihrer Reichweite gehalten wird. Wenn Sie dies als Batch-Job über die root crontab auslösen (vorausgesetzt, die root SSH-Schlüssel stimmen auf allen Computern überein), müssen Sie nicht einmal das Benutzerkonto wechseln, um dies zu tun . Drücken Sie einfach eine Benachrichtigung , wenn Sie fertig sind, und sie werden begeistert sein.

Wie ich immer sagte, wenn sie in der Benutzerunterstützung arbeiten: Was sie nicht anklicken können, können sie nicht durcheinander bringen.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...