it-swarm.com.de

Ist `locken {etwas} | Sudo Bash - eine einigermaßen sichere Installationsmethode?

Der einfachste Weg, NodeJS unter Ubuntu oder Debian zu installieren, scheint Nodesource zu sein, dessen Installationsanweisungen zum Ausführen sagen:

curl -sL https://deb.nodesource.com/setup_12.x | Sudo -E bash -

Dies kollidiert mit einigen grundlegenden Sicherheitsregeln, die ich vor langer Zeit gelernt habe, wie "Seien Sie misstrauisch gegenüber Downloads" und "Seien Sie vorsichtig mit Sudo". Allerdings habe ich diese Regeln schon vor langer Zeit gelernt, und heutzutage scheint es so, als ob jeder dies tut ... nun, zumindest hat es 50 positive Stimmen auf askubuntu.com .

Wenn ich verschiedene Meinungen auf anderen Websites lese, stelle ich fest, dass einige Leute auch Curl-Pipe-Sudo-Bash für unsicher halten:

während einige Leute denken, dass es genauso sicher ist wie jede andere praktische Installationsmethode:

Es gibt auch einige, die das Problem untersuchen, ohne eine entscheidende Meinung abzugeben:

Da es keinen klaren Konsens von anderen Standorten gibt, frage ich hier: Ist Curl-Pipe-Sudo-Bash eine einigermaßen sichere Installationsmethode oder birgt sie unnötige Risiken, die durch eine andere Methode vermieden werden können?

47
Krubo

Es ist ungefähr so ​​sicher wie jeder andere Standard1 Installationsmethode solange Sie:

  • Verwenden Sie HTTPS (und lehnen Sie Zertifikatfehler ab)
  • Vertrauen Sie auf Ihren Certificate Trust Store
  • Vertrauen Sie dem Server, von dem Sie herunterladen

Sie können und sollten die Schritte trennen - laden Sie das Skript herunter2Überprüfen Sie es, und prüfen Sie, ob es etwas faul ist, bevor Sie es ausführen das Skript, das Sie heruntergeladen haben3. Das ist eine gute Idee. Es wird nichts schaden, wenn Sie es tun, und Sie könnten einen Kompromiss finden, den Sie der Quelle und der Community insgesamt melden können. Seien Sie bereit, eine Menge Bash zu durchforsten, wenn meine Erfahrung mit solchen Dingen ein Indikator ist. Sie können auch versuchen, es zu "erweitern", indem Sie alle Skripte herunterladen, die separat erstellt werden sollen, und das Skript optimieren, um diese aufzurufen, wenn Sie sich besonders Sorgen über böse Server machen. Irgendwann müssen Sie sich jedoch entscheiden, nur einen anderen Server zu verwenden Vertraue dem ersten so wenig.

Beachten Sie, dass Sie grundsätzlich keinen Rückgriff haben, wenn der Server (deb.nodesource.com) Gefährdet ist. Viele Paketmanager bieten an, GPG-Signaturen auf Paketen zu überprüfen, und obwohl ein grundlegender Teil der Keysigning-Architektur fehlerhaft ist , funktioniert dies im Großen und Ganzen immer noch. Sie können die Zertifizierungsstelle für wget und curl manuell angeben. Dies beweist jedoch nur, dass Sie wirklich eine Verbindung zu diesem Server herstellen. nicht ​​dass der Server sicheren Code bereitstellt oder dass es sich um legitimen Code der Ersteller handelt.4

Wenn Sie sich Sorgen über die Ausführung von willkürlichem Code machen, lässt APT definitiv dies zu, und ich bin ziemlich sicher, dass sowohl Homebrew als auch Yum dies ebenfalls tun. Es ist also vergleichsweise nicht unsicher. Diese Methode ermöglicht eine bessere Sichtbarkeit. Sie wissen genau, was passiert: Eine Datei wird heruntergeladen und dann von Bash als Skript interpretiert. Die Chancen stehen gut, dass Sie bereits über genügend Kenntnisse verfügen, um das Skript zu untersuchen. Im schlimmsten Fall kann der Bash eine andere Sprache aufrufen, die Sie nicht kennen, oder eine kompilierte ausführbare Datei herunterladen und ausführen, aber selbst diese Aktionen können bemerkt werden vorher und, wenn Sie dazu neigen, untersucht werden.

Als Randnotiz: Angesichts der Tatsache, dass Sie häufig Dinge mit Sudo installieren müssen, sehe ich die Verwendung hier nicht als besonderes Anliegen. Es ist leicht beunruhigend, ja, aber nicht mehr als Sudo apt install ....


1: Es gibt natürlich wesentlich sicherere Paketmanager - ich spreche nur von Standard-Paketmanagern wie APT und yum.

2: ... natürlich vorsichtig mit Ihren Kopien/Pasten. Wenn Sie nicht wissen, warum Sie mit Ihren Kopien/Pasten vorsichtig sein sollten, beachten Sie diesen HTML-Code: Use this command: <code>echo 'Hello<span style="font-size: 0">, Evil</span>!'</code>. Versuchen Sie aus Sicherheitsgründen, einen Texteditor (GUI) einzufügen, und stellen Sie sicher, dass Sie das kopiert haben, was Sie zu tun glauben. Wenn Sie dies nicht getan haben, hören Sie auf, diesem Server zu vertrauen sofort.

3: Sie können tatsächlich erkennen, ob das Skript gerade heruntergeladen oder heruntergeladen und ausgeführt wird, da das Interpretieren eines Skripts mit Bash eine andere Zeit in Anspruch nimmt als das Speichern in einer Datei, und das Linux-Pipe-System "sichern" kann. Dadurch können diese Zeitunterschiede für den Server sichtbar werden. Wenn Sie den genauen Befehl curl | Sudo bash Ausgeführt haben, ist Ihre Prüfung (zumindest wenn es sich um einen böswilligen Server handelt ...) bedeutungslos.

4: Andererseits sieht es so aus, als würde NodeSource eine Art benutzerdefiniertes Installationsprogramm erstellen, das vom Node -Team nicht signiert würde sowieso, also ... bin ich nicht überzeugt, dass es in diesem speziellen Fall weniger sicher ist.

39

Es gibt drei wichtige Sicherheitsfunktionen, die Sie beim Vergleich der Installation von curl ... | bash Mit einem Unix-Distributionsverpackungssystem wie apt oder yum berücksichtigen sollten.

Die erste besteht darin, sicherzustellen, dass Sie die richtigen Dateien anfordern. Apt führt dazu eine eigene Zuordnung von Paketnamen zu komplexeren URLs durch. Der OCaml-Paketmanager ist nur opam und bietet eine ziemlich einfache Überprüfung. Wenn ich dagegen die Curl/Shell-Installationsmethode von opam verwende, muss ich die URL https://raw.githubusercontent.com/ocaml/opam/master/Shell/install.sh Überprüfen und dabei mein persönliches Wissen verwenden, dass raw.githubusercontent.com Eine gut geführte Site ist (im Besitz von GitHub). Es ist unwahrscheinlich, dass das Zertifikat kompromittiert wird, dass es tatsächlich die richtige Site zum Herunterladen von Rohinhalten aus GitHub-Projekten ist. Das GitHub-Konto ocaml ist in der Tat der Anbieter, dessen Software ich installieren möchte, und opam/master/Shell/install.sh ist der richtige Pfad zu der gewünschten Software. Dies ist nicht besonders schwierig, aber Sie können hier die Möglichkeiten für menschliches Versagen sehen (im Vergleich zur Überprüfung von apt-get install opam) Und wie sie mit noch weniger klaren Websites und URLs vergrößert werden können. Auch in diesem speziellen Fall könnte ein unabhängiger Kompromiss zwischen einem der beiden oben genannten Anbieter (GitHub und das OCaml-Projekt) den Download gefährden, ohne dass der andere viel dagegen tun kann.

Die zweite Sicherheitsfunktion bestätigt, dass die Datei, die Sie erhalten haben, tatsächlich die richtige für den obigen Namen ist. Die Curl/Shell-Methode basiert ausschließlich auf der von HTTPS bereitgestellten Sicherheit, die auf der Serverseite (unwahrscheinlich, solange der Serverbetreiber große Sorgfalt walten lässt) und auf der Clientseite (weitaus häufiger als gedacht) gefährdet sein kann Alter von TLS-Abfangen ). Im Gegensatz dazu lädt apt im Allgemeinen über HTTP herunter (wodurch die gesamte TLS-PKI irrelevant wird) und überprüft die Integrität von Downloads über eine PGP-Signatur, die erheblich einfacher zu sichern ist (da die geheimen Schlüssel nicht online sein müssen usw.). .

Der dritte besteht darin, sicherzustellen, dass der Anbieter selbst keine schädlichen Dateien verteilt, wenn Sie die richtigen Dateien vom Anbieter haben. Dies hängt davon ab, wie zuverlässig die Verpackungs- und Überprüfungsprozesse des Anbieters sind. Insbesondere würde ich eher den offiziellen Debian- oder Ubuntu-Teams vertrauen, die Release-Pakete unterzeichnen, um ein besser geprüftes Produkt zu produzieren, sowohl weil dies die Hauptaufgabe dieser Teams ist als auch weil sie darüber hinaus eine zusätzliche Überprüfungsebene durchführen von dem, was der vorgelagerte Anbieter getan hat.

Es gibt auch eine zusätzliche, manchmal wertvolle Funktion, die von Verpackungssystemen wie apt bereitgestellt wird und die möglicherweise von Systemen bereitgestellt wird, die das Curl/Shell-Installationsverfahren verwenden: Prüfung der installierten Dateien. Da apt, yum usw. für die meisten von einem Paket bereitgestellten Dateien Hashes haben, können Sie eine vorhandene Paketinstallation (mit Programmen wie debsums oder rpm -v) Überprüfen, um festzustellen, ob welche vorhanden sind dieser installierten Dateien wurden geändert.

Die Curl/Shell-Installationsmethode bietet einige potenzielle Vorteile gegenüber der Verwendung eines Verpackungssystems wie apt oder yum:

  1. Im Allgemeinen erhalten Sie eine viel neuere Version der Software. Insbesondere wenn es sich um ein Verpackungssystem selbst handelt (z. B. Pip oder Haskell Stack), wird möglicherweise regelmäßig überprüft (sofern verwendet), um festzustellen, ob die Software aktuell ist und angeboten wird ein Update-System.

  2. Bei einigen Systemen können Sie die Software ohne Rootberechtigung (d. H. In Ihrem Home-Verzeichnis, das Ihnen gehört) installieren. Während beispielsweise die von install.sh Installierte Binärdatei opam standardmäßig in /usr/local/bin/ Abgelegt wird (was auf vielen Systemen Sudo-Zugriff erfordert), gibt es keinen Grund, den Sie nicht eingeben können es in ~/.local/bin/ oder ähnlichem, wodurch dem Installationsskript oder der nachfolgenden Software niemals Root-Zugriff gewährt wird. Dies hat den Vorteil, dass sichergestellt wird, dass Root-Kompromisse vermieden werden, obwohl es für spätere Softwareläufe einfacher ist, die installierte Version der von Ihnen verwendeten Software zu gefährden.

17
cjs

Senden einer Antwort auf meine eigene Frage. Ich bin mir nicht sicher, ob dies die beste Antwort ist, aber ich hoffe, dass andere Antworten diese Punkte ansprechen.

curl {something} | Sudo bash - unter Linux ist genauso sicher wie das Herunterladen unter Windows und das Klicken mit der rechten Maustaste als Administrator ausführen. Man kann argumentieren, dass dies "einigermaßen sicher" ist, aber wie ein neuer --- xkcd schlägt vor, niemand weiß es wirklich wie schlecht die Computersicherheit heutzutage ist. In jedem Fall ist diese Methode NICHT so sicher wie andere Installationsmethoden.

Alle sichereren Methoden beinhalten einen Schritt zu überprüfen Sie die Download-Integrität , bevor Sie etwas installieren, und es gibt keinen guten Grund, diesen Schritt zu überspringen. In Installationsprogrammen wie apt ist eine Form dieses Schritts integriert. Ziel ist es, sicherzustellen, dass das, was Sie heruntergeladen haben, dem entspricht, was der Herausgeber beabsichtigt hat. Dies garantiert nicht, dass die Software frei von eigenen Schwachstellen ist, sollte jedoch zumindest vor einfachen Angriffen schützen, die den Download durch Malware ersetzen. Die Essenz besteht einfach darin, die vom Softwarehersteller veröffentlichten MD5- und SHA256-Prüfsummen zu überprüfen. Einige weitere Verbesserungen sind möglich:

  • Es ist besser, diese Prüfsummen über einen anderen Netzwerkpfad abzurufen, z. B. indem Sie einen Freund in einem anderen Land anrufen, um sich vor MITM-Angriffen zu schützen.
  • Es ist besser, die Prüfsummen mindestens einen Tag früher/später zu erhalten, um zu schützen, falls die Website des Herausgebers kurzzeitig übernommen wurde, die Übernahme jedoch innerhalb eines Tages gestoppt wurde.
  • Es ist besser, die Prüfsummen selbst mit GPG zu überprüfen, um zu schützen, falls die Website des Herausgebers kompromittiert wurde, der private GPG-Schlüssel jedoch nicht.

Ein Nebenkommentar: Einige Websites sagen, Sie sollten das Skript sh herunterladen und es dann überprüfen, bevor Sie es ausführen. Leider gibt dies ein falsches Sicherheitsgefühl, es sei denn, Sie überprüfen das Skript mit einer praktisch unmöglichen Genauigkeit. Das Shell-Skript besteht wahrscheinlich aus einigen hundert Zeilen, und sehr kleine Änderungen (z. B. eine verschleierte Änderung einer URL um ein Zeichen) können ein Shell-Skript in ein Malware-Installationsprogramm konvertieren.

4
Krubo

"Ziemlich sicher" hängt von Ihren Torpfosten ab, aber curl | bash liegt weit hinter dem Stand der Technik.

Werfen wir einen Blick auf die Art der Überprüfung, die man sich wünschen könnte:

  • Stellen Sie sicher, dass jemand, der bei Ihrem ISP böswillig ist, keinen Man-in-the-Middle ausführen kann, um Ihnen beliebigen Code zuzuführen.
  • Stellen Sie sicher, dass Sie dieselben Binärdateien erhalten, die der Autor veröffentlicht hat
  • Stellen Sie sicher, dass Sie dieselben Binärdateien erhalten, die auch jemand heruntergeladen hat, der denselben Dateinamen heruntergeladen hat.
  • Stellen Sie sicher, dass die von Ihnen heruntergeladenen Binärdateien einen bestimmten, überprüfbaren Satz von Quellen und Erstellungsschritten widerspiegeln und von diesen reproduziert werden können.
  • Trennen Installieren von Software von Ausführen von Software - wenn Sie Software installieren Um von einem nicht vertrauenswürdigen Benutzer mit niedrigen Berechtigungen ausgeführt zu werden, sollte dabei kein Konto mit hohen Berechtigungen gefährdet werden.

Mit curl | Sudo bash, du bekommst nur den ersten wenn das; mit rpm oder dpkg erhalten Sie einige davon; Mit nix können Sie alle erhalten.

  • Wenn Sie curl zum Herunterladen über https verwenden, haben Sie eine gewisse Sicherheit gegen einen Angreifer in der Mitte, sofern dieser Angreifer kein Zertifikat und keinen Schlüssel fälschen kann, die für den Remote-Standort gültig sind . (Sie haben keine Sicherheit gegen einen Angreifer, der in den Remote-Server eingebrochen ist, oder gegen einen Angreifer, der Zugriff auf die lokale Zertifizierungsstelle hat, die Ihr Unternehmen in alle Zertifizierungsstellen gestellt hat Speichern Sie Listen auf firmeneigener Hardware, damit sie ausgehende SSL-Verbindungen mit MITM für absichtliche "Sicherheitszwecke" abwickeln können!).

    Dies ist das einzige Bedrohungsmodell curl | Sudo bash schützt dich manchmal erfolgreich vor.

  • Um sicherzustellen, dass Sie dieselben Binärdateien erhalten, die der Autor veröffentlicht hat, kann dieser Autor eine digitale Signatur verwenden (Linux-Distributionen verteilen normalerweise einen Schlüsselbund mit OpenPGP-Schlüsseln von Personen, die berechtigt sind, Pakete für diese Distribution zu veröffentlichen, oder haben einen Schlüssel, für den sie verwenden Pakete, die sie selbst erstellt haben, und verwenden Zugriffskontrollmaßnahmen, um einzuschränken, welche Autoren Pakete in ihre Build-Systeme aufnehmen können.

    Bei korrekter Bereitstellung bietet rpm oder dpkg diese Sicherheit; curl | bash nicht.

  • Es ist schwieriger sicherzustellen, dass , die denselben Namen anfordern, immer dieselben Binärdateien zurückgibt, wenn der Schlüssel eines autorisierten Autors hätte erfasst werden können. Dies kann jedoch erreicht werden, wenn der heruntergeladene Inhalt Hash-adressiert ist ; Um verschiedene Inhalte unter demselben Namen zu veröffentlichen, müsste ein Angreifer entweder die Eingaben vom Hash vom Inhalt der Datei entkoppeln (trivial erkannt, wenn es sich um den Hash der veröffentlichten Binärdatei handelt.

    Die Umstellung auf eine Hash-adressierte Build-Veröffentlichung hat zwei mögliche Ansätze:

    • Wenn der Hash von den Ausgaben des Builds stammt, besteht der einfachste Ansatz eines Angreifers darin, den Mechanismus zu finden, mit dem der Endbenutzer diesen Hash nachgeschlagen hat, und ihn durch einen böswilligen Wert zu ersetzen - also bewegt sich der Angriffspunkt, aber der Verwundbarkeit selbst nicht.

    • Wenn der Hash aus den Eingaben für den Build besteht, erfordert die Überprüfung, ob die Ausgabe des Builds wirklich mit diesen Eingaben übereinstimmt, mehr Arbeit (dh das Ausführen des Builds!), Um zu überprüfen, aber diese Überprüfung ist weitaus schwieriger zu umgehen.

    Der letztere Ansatz ist der bessere, obwohl es teuer ist, die Leute zu überprüfen und zusätzliche Arbeit für die Leute zu leisten, die Software-Pakete erstellen (um mit allen Stellen umzugehen, an denen der Autor eines Programms Zeitstempel oder andere nicht reproduzierbare Elemente gefaltet hat, um den Prozess selbst zu erstellen).

    Der Umgang mit böswilligen Autoren gehört nicht zum Sicherheitsmodell, das rpm oder dpkg zu adressieren versucht, und natürlich curl | bash tut auch nichts dagegen.

  • Das Trennen der Installation von der Laufzeit ist eine Frage des Entwurfs des Serialisierungsformats im Voraus ohne gefährliche Funktionen - ohne Unterstützung von setuid oder setgid Bits, ohne Unterstützung von nicht sandboxed Ausführungsskripten zur Installationszeit mit beliebigem Code usw. . curl | Sudo bash bietet Ihnen hier keinen Schutz, aber rpm und dpkg auch nicht. Im Gegensatz dazu lässt nix jeden nicht privilegierten Benutzer Software in den Store installieren. Das verwendete NAR-Serialisierungsformat stellt jedoch keine Setuid- oder Setgid-Bits dar. Dieser Inhalt im Store wird von keinem Benutzerkonto referenziert, das dies nicht tut Fordern Sie es nicht explizit an oder eine davon abhängige Software, und Fälle, in denen Software setuid Berechtigungen für die Installation benötigt, erfordern explizite Out-of-Band-Verwaltungsaktionen, bevor diese Bits tatsächlich gesetzt werden.

    Nur seltsame, Nischen- und Spezialsoftware-Installationsmethoden wie nix machen das richtig.

4
Charles Duffy

Eine Möglichkeit wäre, zu versuchen, eine Verhaltensanalyse der Ergebnisse durchzuführen, indem der Befehl curl separat ausgeführt wird, um eine Kopie des Skripts abzurufen.

Führen Sie es dann in einer Linux-VM aus und beobachten Sie, welche Verbindungen hergestellt werden usw. Sie können sogar die Überwachung der Dateiintegrität auf dem System ausführen und sehen, was sich bei der Ausführung geändert hat.

Letztendlich ist der Kontext wichtig, dass dieses Verhalten zu Kompromissen führen kann, aber es ist nicht besonders schlimmer als viele der anderen Methoden, mit denen Menschen Software erhalten. Selbst bei der oben erwähnten Verhaltensanalyse sind Sie durch die sekundären Quellen eingeschränkt, aus denen das Skript möglicherweise abgerufen wird, was ebenfalls dynamisch sein kann. Dies gilt jedoch auch für die Abhängigkeiten realer Software. Auf einer bestimmten Ebene müssen Sie sich also auf das Vertrauen verlassen die Quelle, um etwas Schlechtes nicht zu verlinken.

1
pacifist

Nein, es ist nicht so sicher. Ihr Download kann in der Mitte fehlschlagen.

Wenn Ihr Download in der Mitte fehlschlägt, haben Sie ein Teilskript ausgeführt, das möglicherweise einige Vorgänge (Bereinigung, Konfiguration usw.) nicht ausführen kann.

Es ist nicht wahrscheinlich, wenn das Skript klein ist oder Ihre Verbindung schnell ist, aber es ist möglich, insbesondere bei einer langsamen Verbindung.

Dies ist ein Beispiel für den Unterschied zwischen Sicherheit und Schutz. :) :)

0
user541686