curlからbashへ直流しは危ない｜bashkaで中身を検める

手順書やツールの公式サイトに「この1行を貼り付けるだけ」と書かれたインストール手順があります。コピーして、そのままターミナルに流していませんか。

この記事では、curlで落としたスクリプトをbashへ直接流す危うさと、実行する前に中身を検める具体的な手順をまとめます。話題の検査ツール「bashka」も題材にします。

結論を先に言います。危ないのはコマンドそのものではなく「読まずに実行する」ことです。1行を2行に分けるだけで、危険の大半は避けられます。

curlからbashへ直流しとは?あの1行が裏でやっていること

結論から言うと、あの1行は「ダウンロード」と「実行」を同時にやっています。

curlは、URLの中身を取ってくるだけのコマンドです。その出力をパイプでbashに渡すと、届いた文字列がそのまま命令として動き出します。

身近な例でたとえます。通販で届いた箱を、中身を見ないまま開けて、同封の紙に書かれた指示にそのまま従うようなものです。差出人を信じているからできる行為だと言えます。

やっかいなのは、スクリプトがファイルとしてディスクに残らない点です。あとから「あのとき何が実行されたのか」を読み返す手段がありません。

つまり直流しは、確認の機会そのものを消してしまう書き方なのです。

なぜcurl直流しが危ないのか｜現場で効く3つのリスク

危ないと言われる理由は、気分の問題ではなく、はっきりした3つの仕組みにあります。

• 読む機会がない: 画面には進捗しか出ず、何をされたか分からないまま終わります
• サーバー側で中身を出し分けできる: ブラウザで開いたときと、コマンドで取得したときで、別の内容を返せます
• 2段目が隠せる: 1段目は無害で、途中から別のURLの本体を落としてくる作りにできます

1つ目と3つ目は想像しやすいはずです。2つ目は「同じURLなら同じ内容が返る」という思い込みを突いてきます。bashkaの作者も、実行時にサーバーが別の内容を返す可能性を、検査では防げない限界として挙げています。

さらに、この1行はsudoを付けて案内されることがあります。管理者権限で動けば、影響は自分のホームディレクトリの外まで届きます。

運用や監視の現場だと、作業するのは共用のサーバーです。自分1人で完結しないからこそ、直流しの一手間を惜しまない価値があります。

bashkaとは?スクリプトを実行前に検査して色分けするツール

bashkaは、パイプの行き先をbashからbashkaに変えるだけで、実行前に中身を検査してくれるツールです。

使い方はとても単純で、末尾を差し替えるだけです。案内された「curl -fsSL URL | bash」を「curl -fsSL URL | bashka」と書きます。検査は、スクリプトを読み解いて危険なパターンを点数化する方式です。

結果は4段階で示されます。

• 致命的: 認証情報の盗み出し、外部サービスへのデータ送信、リバースシェル
• 赤信号: 難読化、危険な削除(rm -rf /など)、痕跡消し(履歴やログの消去)、TLS検証の無効化、2段目を落とす作り
• 注意: 検証なしのダウンロード、指定先が動いてしまうバージョン参照
• 良い兆候: チェックサムの検証、HTTPSのみの通信、bashの厳格モード

意外なのがsudoの扱いです。bashkaはsudoやdoasを使うこと自体を「注意」に分類し、判定そのものは変えません。権限が要る導入は珍しくないからです。赤信号になるのは、痕跡消しやTLS検証の無効化のように、正当な理由を説明しにくい動きのほうです。

設定で赤信号のときに一度止めて確認を求めたり、転送先のスクリプトまで自動でたどって検査させたりもできます。

なお、bashka自体の入れ方として公式が案内しているのも、やはりcurlからbashへ流す1行です(作者も「最後にもう一度だけ」と添えています)。その1行を使いたくなければ、HomebrewやCargo、miseから入れるか、リリースページのバイナリを添付のチェックサムと照合して置く方法が用意されています。

もう1つ便利なのが台帳の機能です。入れたソフトをファイルに記録し、一覧表示・削除・入れ直しをコマンドで扱えます。野良インストールの棚卸しが苦手な現場ほど、この記録が効いてきます。

bashkaでも分からないこと｜静的検査の限界を先に知る

ここは筆者が一番大事だと考えている部分です。検査を通したから安全、という受け取り方が一番危ないと思っています。

理由は、作者自身が限界を正直に並べているからです。主なものは次の4つです。

• bashは何でも書ける言語なので、あらゆる難読化を見抜くことはできない
• PATH経由のbashやshしか捕まえられず、直接パスを書かれると素通りする
• サーバーが実行の瞬間に別の内容を返す可能性は、事前の検査では消せない
• 監視していない場所に置かれたファイルは、台帳に残らない

火災報知器にたとえると分かりやすいはずです。鳴れば異常が分かりますが、鳴らないことは「火が出ない保証」ではありません。

bashkaは「緑だから安心する道具」ではなく「赤を見逃さないための道具」です。そう受け取ると、使い方を間違えずに済みます。

curl直流しと付き合う3手順｜運用・監視の現場で今日からできること

結論として、道具を入れる前にできることが3つあります。ツールを導入できない職場でも、今日から実行できる内容です。

1. 1行を2行に分ける: いったんファイルに保存し、中を読んでから実行します。証拠も手元に残ります
2. 読む場所を決めておく: 通信先のURL、sudoの有無、削除コマンド、環境変数の送信、2段目のダウンロードの5点です
3. 入れたものを記録する: 日付・取得元URL・入れた理由をメモします。チームのWikiでも十分です

とくに2つ目は、身につければ一生使える観点です。環境変数の送信に目が行くようになると、APIキーを.envに置くのが危ない理由で扱った話ともつながってきます。

3つ目の記録は、事故が起きたあとに効きます。何をいつ入れたか分かれば、アクセスログから侵害の兆候を見つける集計と突き合わせて、原因を絞り込めます。

入れるときの慎重さが、あとの調査を楽にします。

サーバーの土台のコマンドそのものが入れ替わる話は、UbuntuのlsがRust製になった影響にまとめています。

まとめ

• curlからbashへの直流しは、ダウンロードと実行を同時に行い、確認の機会を消してしまう
• bashkaはパイプの行き先を差し替えるだけで中身を検査し、危険度を4段階で示してくれる
• 静的検査には限界があるため、道具に頼りきらず「2行に分けて読む」習慣を土台にする

次にインストール手順をコピーするときは、末尾のbashを消して、ファイルに保存するところから始めてみてください。

参考リンク

• dmtrKovalenko/bashka(GitHub・公式リポジトリ) ― 検査項目の一覧、4段階の分類、設定ファイルの項目、作者が挙げる限界(Limitations)
• bashkaのインストールスクリプト(公式・生のファイル) ― 作者が「自分で読んでほしい」と案内している実物