「カール{何か} | Sudo bash -`合理的に安全なインストール方法？

Question

NodeJSをUbuntuまたはDebianにインストールする最も簡単な方法はNodesourceであり、その インストール手順 は次のように実行します。

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

これは、「ダウンロードに疑いを持つ」、「Sudoに注意する」など、私が以前に学んだいくつかの基本的なセキュリティルールと衝突します。しかし、私はずっと前にそれらのルールを学びました、そして今日では誰もがこれをやっているようです...まあ、少なくとも askubuntu.comで350の賛成票 を持っています。

他のサイトでさまざまな意見を読んでいると、curl-pipe-Sudo-bashは安全でないと考える人もいることがわかりました。

• Phil。（idontplaydarts.com、2016-04-19） "curl | bash"サーバー側の使用の検出
• Stemm、Mark。（Sysdig.com、2016-06-13）友達は友達にカールを許可させない| Bash。
• Stackoverflow.com。（2015-04-01以降）curlを使用する理由| Sudo shは推奨されませんか？ （ askubuntuからもリンクされています ）

他の実用的なインストール方法と同じくらい安全だと考える人もいますが、

• McLellan、Bryan。（Github.com/btm、2013-09-25）なぜカールするのか| Sudo bashが良い。
• YCombinator.com。（2016-10-22以降）恥の「カールバッシュパイピング」壁
• Varda、Kenton。（Sandstorm.io、2015-09-24）curl | bashは安全ではありませんか？ 。

決定的な意見を与えることなく問題を探究する人もいます：

• Granquist、Lamont。（Chef.io、2015-07-16）install.sh Curl Pipe Bashの問題に対処する5つの方法

他のサイトからの明確なコンセンサスがないので、私はここで尋ねています：curl-pipe-Sudo-bashはかなり安全なインストール方法ですか、それとも他の方法で回避できる不必要なリスクを伴いますか？

Answer 1

他の標準と同じくらい安全です¹ インストール方法：

• HTTPSを使用（および証明書エラーを拒否）
• 証明書の信頼ストアに自信がある
• ダウンロード元のサーバーを信頼する

ステップを分離することはできますし、すべきです-スクリプトをダウンロードしてください²、それを調べ、ダウンロードしたスクリプトを実行する前に怪しいことをしていないか確認します^３。これは良い考えです。これを行っても何も害はなく、妥協点を見つけられるかもしれません。ソースやコミュニティ全体に報告できます。そのようなものでの私の経験が何らかの指標であるなら、かなり多くのBashを掘り下げる準備をしてください。また、特に悪意のあるサーバーについて心配している場合は、それを「拡張」して、個別に実行するスクリプトをダウンロードし、それらを呼び出すようにスクリプトを微調整することもできますが、場合によっては、別のサーバーを使用することを決定する必要があります。最初のものを少しだけ信頼してください。

サーバー（deb.nodesource.com）が危険にさらされている場合、基本的には頼りにならないことに注意してください。多くのパッケージマネージャーは、パッケージのGPG署名を検証することを提案しています。 キー署名アーキテクチャーの基本的な部分が壊れている であるにもかかわらず、これは依然として大きな作業です。 wget および curl のCAを手動で指定できますが、これは実際にそのサーバーに接続していることを証明するだけであり、ではありませんサーバーが安全なコードを提供していること、または作成者からの正当なコードであること。⁴

任意のコードの実行が心配な場合は、APTdefinitelyでそれが可能になり、両方のHomebrewにかなり自信があるおよびYumも実行します。そのため、比較的安全ではありません。この方法により、可視性が向上し、何が起こっているのかを正確に把握できます。ファイルがダウンロードされ、Bashによってスクリプトとして解釈されます。奇数スクリプトの調査を開始するのに十分な知識があれば十分です。最悪の場合、Bashは知らない別の言語を呼び出したり、コンパイルされた実行可能ファイルをダウンロードして実行したりできますが、それらのアクションにも気づくことができますbeforehandそして、もしあなたがそうしたいと思っているなら、調査してください。

補足として、Sudoを使用してインストールする必要がある場合が多いので、ここでの使用は特別な懸念とは見なしません。はい、やや戸惑いですが、Sudo apt install ...にすぎません。

---

^{1： かなり安全なパッケージマネージャーがあります もちろん、-APTとyumのような標準的なものについてのみ話しています。}

^{2：...当然ながら、コピー/貼り付けに注意しながら。コピー/貼り付けに注意する必要がある理由がわからない場合は、次のHTMLを検討してください：Use this command: <code>echo 'Hello<span style="font-size: 0">, Evil</span>!'</code>。安全のために、（GUI）テキストエディターに貼り付けて、意図したとおりにコピーしたことを確認してください。そうしなかった場合は、そのサーバーの信頼を停止します即時。}

^{3：Bashを使用したスクリプトの解釈にはファイルへの保存とは異なる時間がかかり、Linuxのパイプシステムは「バックアップ」できるため、スクリプトがダウンロードされているだけなのか、ダウンロードされて実行されたのかを実際に検出できます。これにより、これらのタイミングの違いがサーバーから見えるようになります。彼らが与えた正確なcurl | Sudo bashコマンドを実行した場合、調査は（少なくとも悪意のあるサーバーであれば...）意味がありません。}

^{4：次に、NodeSourceが何らかのカスタムインストーラーを作成しているように見えますが、Node teamanyway、だから...この特定のケースでは安全性が低いとは思いません。}

Answer 2

curl ... | bashのインストールをaptやyumのようなUnixディストリビューションパッケージシステムと比較する際に確認したい3つの主要なセキュリティ機能があります。

1つ目は、正しいファイルをリクエストしていることを確認することです。 Aptは、より複雑なURLへのパッケージ名の独自のマッピングを維持することにより、これを行います。 OCamlパッケージマネージャーはopamであり、検証が非常に簡単です。対照的に、opamのcurl/Shellインストール方法を使用する場合は、https://raw.githubusercontent.com/ocaml/opam/master/Shell/install.shが実行されている（GitHubが所有および実行している）可能性の低いサイトであるという個人的な知識を使用して、URL raw.githubusercontent.comを確認する必要があります。証明書が危険にさらされているため、GitHubプロジェクトから生のコンテンツをダウンロードするための正しいサイトであり、ocaml GitHubアカウントは、インストールするソフトウェアのベンダーであり、opam/master/Shell/install.shが正しい欲しいソフトウェアへのパス。これはそれほど難しくありませんが、ここで人為的エラーが発生する可能性（apt-get install opamの確認と比較）を確認でき、サイトやURLをさらに明確にしない場合に拡大する方法を確認できます。この特定のケースでも、上記の2つのベンダー（GitHubとOCamlプロジェクト）のいずれかの独立した侵害により、他のベンダーがそれについて多くのことを実行できなくても、ダウンロードが侵害される可能性があります。

2番目のセキュリティ機能は、取得したファイルが実際に上記の名前に対して正しいものであることを確認することです。 curl/Shellメソッドは、HTTPSによって提供されるセキュリティにのみ依存します。これは、サーバー側（サーバーオペレーターが十分な注意を払っている限りは）とクライアント側（これで考えるよりもはるかに頻繁）で危険にさらされる可能性があります。 TLSインターセプトの年齢 ）。対照的に、aptは一般にHTTPを介してダウンロードし（したがって、TLS PKI全体を無関係にレンダリングし）、PGPシグネチャを介してダウンロードの整合性をチェックします。これは、保護がかなり簡単です（秘密鍵をオンラインにする必要がないためなど）。 。

3つ目は、ベンダーから正しいファイルを入手したときに、ベンダー自体が悪意のあるファイルを配布していないことを確認することです。これは、ベンダーのパッケージ化とレビュープロセスの信頼性にかかっています。特に、リリースパッケージに署名した公式のDebianチームまたはUbuntuチームは、チームの主な仕事であり、さらに上位のレビュー層を追加しているため、よりよく吟味された製品を生産していると信頼する傾向があります。上流のベンダーがしたことの。

Curl/Shellインストール手順を使用するシステムによって提供される場合とされない場合があるaptなどのパッケージシステムによって提供される、時には価値のある追加機能もあります。インストールされたファイルの監査です。 apt、yumなどは、パッケージによって提供されるほとんどのファイルのハッシュを持っているため、既存のパッケージのインストールをチェックして（debsumsやrpm -vなどのプログラムを使用して）、これらのインストール済みファイルは変更されています。

Curl/Shellのインストール方法には、aptやyumなどのパッケージシステムを使用する場合に比べて、いくつかの潜在的な利点があります。

1. 通常、ソフトウェアの最新バージョンを取得しています。特にそれがパッケージシステム自体（pipやHaskell Stackなど）の場合は、定期的にチェックして（使用した場合）、最新かどうかを確認し、更新システム。

2. 一部のシステムでは、ソフトウェアの非ルート（つまり、自分が所有するホームディレクトリ）インストールを実行できます。たとえば、上記のinstall.shによってインストールされたopamバイナリはデフォルトで/usr/local/bin/に入れられますが（多くのシステムでSudoアクセスが必要）、入れられない理由はありません。 ~/.local/bin/またはこれに類似しているため、インストールスクリプトや後続のソフトウェアにルートアクセスを一切許可しません。これには、ルートの侵害を確実に回避できるという利点がありますが、その後のソフトウェアの実行で、使用しているソフトウェアのインストール済みバージョンを侵害することが容易になります。

Answer 3

自分の質問に対する回答を提出する。これが最良の答えかどうかはわかりませんが、他の答えがこれらの点に対処することを望んでいます。

curl {something} | Sudo bash - Linuxでは、Windowsで何かをダウンロードし、右クリックして管理者として実行するのと同じくらい安全です。これは「かなり安全」であると主張することができますが、最近の xkcdが示唆しているように、誰も実際には知りません 最近のコンピュータのセキュリティの悪さです。いずれにしても、この方法は他のインストール方法ほど安全ではありません。

すべてのより安全な方法には、何かをインストールする前に ダウンロードの整合性を検証する へのステップが含まれており、このステップをスキップする正当な理由はありません。 aptのようなインストーラーには、このステップの形式が組み込まれています。目的は、ダウンロードしたものがパブリッシャーの意図したものであることを確認することです。これは、ソフトウェアに脆弱性がないことを保証するものではありませんが、少なくとも、ダウンロードをマルウェアに置き換える単純な攻撃から保護する必要があります。本質は、ソフトウェア発行元が投稿したMD5およびSHA256チェックサムを検証することです。さらにいくつかの改善が可能です：

• MITM攻撃から保護するために、別の国の友達に電話するなど、別のネットワークパスを介してこれらのチェックサムを取得することをお勧めします。
• チェックサムを少なくとも1日早く/遅く取得することをお勧めします。これは、発行者のWebサイトが一時的に引き継がれたが、引き継ぎが1日以内に停止した場合に保護されます。
• GPGを使用してチェックサム自体を確認することをお勧めします。これは、発行者のWebサイトが侵害されたが、GPG秘密キーは侵害されなかった場合に保護します。

一方的なコメント：一部のサイトでは、shスクリプトをダウンロードして、実行する前に検査する必要があるとしています。残念ながら、実際には不可能なレベルの精度でスクリプトを精査しない限り、これは誤った安心感を与えます。シェルスクリプトはおそらく数百行であり、非常に小さな変更（URLへの難読化された1文字の変更など）は、シェルスクリプトをマルウェアインストーラーに変換する可能性があります。

Answer 4

「合理的に安全」はゴールポストに依存しますが、curl | bashは最先端の技術よりもかなり遅れています。

確認したい種類の検証を見てみましょう。

• ISPの悪意のある誰かが中間者を介して任意のコードをフィードできないようにします。
• 著者が公開したものと同じバイナリを確実に入手する
• 同じファイル名をダウンロードしている誰かが入手したものと同じバイナリを確実に入手する。
• ダウンロードしたバイナリが特定の監査可能なソースのセットとビルドステップを反映し、同じものから再現できることを確認します。
• 分離ソフトウェアのインストールからソフトウェアの実行-信頼されていない低特権ユーザーが実行するソフトウェアをインストールする場合、高特権アカウントを危険にさらすべきではありません過程の中で。

curl | Sudo bash、その場合、最初のものだけを取得します。 rpmまたはdpkgを使用すると、それらのいくつかを取得できます。 nixを使用すると、それらすべてを取得できます。

• curlを使用してhttps経由でダウンロードすると、リモートサイトで有効な証明書とキーを偽造できない限り、中間者攻撃に対してある程度の安全性があります。 。 （あなたはしないリモートサーバーに侵入した攻撃者、または会社がローカル所有のCAへのアクセス権を持つ攻撃者が企業所有ハードウェアのすべてのCAストアリストに追加されたため、安全を確保できます。意図的な「セキュリティ」のためのMITM発信SSL接続！）.

  これが唯一の脅威モデルですcurl | Sudo bashはあなたを守るのに成功することがあります。

• 著者が公開したものと同じバイナリを確実に取得できるようにするには、著者がデジタル署名を使用して作成できます（Linuxディストリビューションは、通常、パッケージをそのディストリビューションに公開することを承認された個人に属するOpenPGPキーのキーチェーンを配布するか、またはそれらが使用するキーを持っています自分でビルドしたパッケージ、およびアクセス制御手段を使用して、ビルドシステムにパッケージを取得できる作成者を制限します）。

  正しくデプロイされた場合、rpmまたはdpkgはこの安全性を提供します。curl | bashは行いません。

• 承認された作成者のキーが取得されている可能性がある場合、同じ名前を要求すると常に同じバイナリが返されるとなるようにするのは難しいです。ただし、ダウンロードするコンテンツがhash-addressed;であれば、これは可能です。同じ名前で異なるコンテンツを公開するには、攻撃者はファイルのコンテンツからハッシュから入力を分離する必要があります（公開されているバイナリのハッシュである場合は、簡単に検出されます）。

  ハッシュアドレス指定ビルドパブリケーションに移行するには、2つの方法があります。

  • ハッシュがビルドの出力のものである場合、攻撃者の最も簡単なアプローチは、エンドユーザーがそのハッシュを調べて悪意のある値に置き換えるメカニズムを見つけることです。そのため、攻撃ポイントは移動しますが、脆弱性自体にはありません。

  • ハッシュがビルドへの入力のものである場合、ビルドの出力がこれらの入力に完全に一致することを確認するには、確認のためにさらに多くの作業（つまり、ビルドを再実行する）を実行する必要がありますが、その確認を回避するのははるかに難しくなります。

  後者のアプローチは、チェックに費用がかかり、ソフトウェアのパッケージングを行う人々に余分な作業を費やしますが（タイムスタンプやその他の再現性のない要素を組み込んだプロセスの作成者がプロセス自体を折りたたむ場所に対処するため）、優れたアプローチです。

  悪意のある作者との取引は、rpmまたはdpkgが対処しようとするセキュリティモデルではなく、もちろんcurl | bashもそれについて何もしません。

• インストールをランタイムから分離することは、危険な機能なしでシリアル化フォーマットを事前に設計することの問題です-setuidまたはsetgidビットをサポートせず、任意のコードを含むインストール時のサンドボックス化されていない実行スクリプトをサポートしないなど。curl | Sudo bashはここでは保護しませんが、rpmとdpkgも保護しません。対照的に、nixは、権限のないユーザーがソフトウェアをストアにインストールできるようにします。ただし、使用するNARシリアル化形式は、setuidビットまたはsetgidビットを表さないため、ストア内のコンテンツは、それまたはそれに依存するソフトウェアの一部を明示的に要求しないでください。ソフトウェアをsetuid特権をインストールする必要がある場合、これらのビットが実際に設定される前に、明示的な帯域外管理アクションが必要です。

  nixのような特殊なソフトウェアのインストール方法であるオッドボール、ニッチ、これのみが正しく機能します。

Answer 5

1つのオプションは、curlコマンドを個別に実行してスクリプトのコピーをフェッチすることで、結果の動作分析を試みることです。

次に、それをlinux vmで実行し、どのような接続が発生するかを監視します。システムでファイル整合性監視を実行し、実行時に何が変更されるかを確認することもできます。

結局のところ、この動作は妥協につながる可能性があるというコンテキストが重要ですが、人々がソフトウェアを入手する他の多くの方法よりも特に悪くはありません。上で述べた行動分析を使用しても、スクリプトが取得する可能性のある二次ソースによって制限されます。これも動的である可能性がありますが、実際のソフトウェアの依存関係も同じであるため、あるレベルでは、信頼に頼る必要があります悪いものをリンクしないためのソース。

Answer 6

いいえ、安全ではありません。ダウンロードが途中で失敗する可能性があります。

ダウンロードが途中で失敗した場合は、部分的なスクリプトを実行したことになります。これにより、想定されていた一部の操作（クリーンアップ、構成など）が失敗する可能性があります。

スクリプトが小さい場合や接続が速い場合は可能性ありではありませんが、特に遅い接続では可能です。

安全と安心の違いの一例です。 :)