Shellshock（CVE-2014-6271）とは？Bashの環境変数に潜むRCE脆弱性の仕組みと今なお続くリスクをわかりやすく解説

サーバー管理をしていると、脆弱性スキャンの結果に「Shellshock」という文字を見かけることがあります。2014年に発覚してから10年以上が経過した今でも、組み込み機器や長期間放置されたレガシーサーバーでは現役の脅威となっています。

Shellshockは「知っていれば確実に防げる」脆弱性の代表例です。GNU Bashの環境変数処理に起因するリモートコード実行（RCE）脆弱性で、発覚当時はWebサーバー・DHCP・SSH経由で広く悪用されました。

この記事では、Shellshock（CVE-2014-6271）の脆弱性の仕組み・主な攻撃経路・確認方法・防御手順を現場で使えるレベルで解説します。組み込み機器や古いNASを管理する方には特に参考になる内容です。

Shellshock（CVE-2014-6271）とは？

Shellshockは、GNU Bashの環境変数処理に存在したリモートコード実行（RCE）脆弱性です。2014年9月にStéphane Chazelas氏によって発見・報告され、翌日には修正版のBashが公開されました。

GNU BashにはBashが起動する際、環境変数から関数定義を引き継ぐ機能があります。この仕組みを悪用し、関数定義の末尾に任意のコマンドを付け加えると、Bashが環境変数を読み込んだ瞬間にそのコマンドが実行されるというバグがありました。

詳細情報: NVD – CVE-2014-6271

CVSSスコアが最高値10.0であり、攻撃の容易さと影響範囲の広さから、同時期に話題になったHeartbleedと並んで「2014年最大の脆弱性」と呼ばれました。CVE番号の仕組みや読み方はこちらの記事で詳しく解説しています。

Shellshockの仕組み（なぜコードが実行されるのか）

Bashには「環境変数を通じて関数を子プロセスに引き継ぐ」機能があります。通常の使い方では、次のような形式で関数定義が環境変数に格納されます。

# 通常の関数エクスポート（正常な動作）
myfunc() { echo "hello"; }
export -f myfunc

# Bashが環境変数として格納した内容（イメージ）
# BASH_FUNC_myfunc%%=() { echo "hello"; }

問題は、Bashがこの環境変数を解析するとき、関数定義に続いて記述されたコマンドも実行してしまうことにあります。概念的に示すと以下の形式です。

# 脆弱なBashが処理してしまうパターン（概念図・実行しないこと）
# 環境変数の値: () { 任意の関数定義; }; 攻撃コマンド
#                                       ^^^^^^^^^^
#                                       ここが問題。関数定義の後ろに
#                                       付け足したコマンドまで実行される

攻撃者はこの「後続部分」に、ファイル読み取り・リバースシェル起動・マルウェアダウンロードなどの任意コマンドを埋め込みます。Bashが環境変数を読み込んだ瞬間にコードが実行されるため、プロセスの権限を引き継いだ形でOSコマンドが走ります。リモートコード実行（RCE）の全体像はこちらで詳しく解説しています。

Shellshockの主な攻撃経路

Shellshockが特に危険だった理由は、複数の経路からリモート攻撃が成立したことです。

1. Apache CGIスクリプト経由（最も多い経路）

Bashで書かれたCGIスクリプト（シバン行が #!/bin/bash のもの）が動作しているWebサーバーが最も多く狙われました。

HTTPリクエストのヘッダー（User-AgentやRefererなど）はWebサーバーが HTTP_USER_AGENT 等の環境変数としてCGIプロセスに渡す仕組みになっています。攻撃者はこのヘッダー値に悪意あるコマンドを埋め込み、CGIプロセスがBashを起動した瞬間にコード実行を成立させます。

# 攻撃者が送信するHTTPリクエスト（概念図）
GET /cgi-bin/example.sh HTTP/1.1
Host: target.example.com
User-Agent: () { :; }; /bin/cat /etc/passwd
# ↑ User-Agentヘッダーに関数定義＋コマンドを埋め込んでいる

2. DHCPクライアント経由

一部のLinuxディストリビューションでは、DHCPクライアントがBashスクリプトを呼び出す際に環境変数を渡す実装になっていました。攻撃者が制御する悪意あるDHCPサーバーがあるネットワーク（公衆Wi-Fi等）に接続した際、DHCP応答に攻撃コードを含めてクライアント側でコードを実行させることが可能でした。

3. OpenSSH ForceCommand経由

SSHの ForceCommand ディレクティブは、ユーザーを特定のコマンドのみに限定する機能です。しかし脆弱なBashでは、SSH環境変数経由でこの制限を回避してコードを実行できるケースがありました。

4. その他のスクリプト・フック

・Gitフック: post-receive などのフックスクリプトがBashを使用していた場合、リモートプッシュ操作経由で攻撃が成立する可能性がありました
・メールフィルタリングツール: ProcmailなどのメールフィルターでBashスクリプトを呼び出す環境でも攻撃経路となりえました
・組み込み機器のWebインターフェース: ルーター・NASの管理画面がCGIでBashを呼び出す実装だった場合に影響を受けました

Shellshock脆弱性の確認と防御手順

1. Bashバージョンの確認

まず現在のBashバージョンを確認します。

bash --version
# GNU bash, version 4.3.xx(x)-release (x86_64-pc-linux-gnu)
# patchlevel 25以降（4.3.25、4.4.0以降）ならパッチ適用済み
# patchlevel 25未満（4.3.24以前）なら要更新

2. 脆弱性チェックコマンド（防御目的の確認）

以下のコマンドで脆弱性の有無を確認できます。自社サーバーでの確認のみに使用してください。

# 脆弱性確認コマンド（自社サーバーの防御的確認のみに使用）
env x='() { :;}; echo "VULNERABLE"' bash -c "echo test" 2>/dev/null

# 出力結果の見方:
# 「VULNERABLE」が表示された → 脆弱なBash。即時パッチ適用が必要
# 「test」だけ表示された    → パッチ適用済みまたは影響なし

3. パッチ適用（Bashの更新）

ディストリビューションのパッケージマネージャーでBashを更新します。

# Debian/Ubuntu系
sudo apt-get update && sudo apt-get install --only-upgrade bash

# RHEL/CentOS/AlmaLinux系
sudo yum update bash
# または
sudo dnf update bash

# 更新後にバージョン再確認
bash --version

4. CGI利用状況の確認と最小化

ApacheでCGIが有効かどうか確認し、不要なら無効化します。

# CGIモジュールが有効かどうか確認（Apache）
apache2ctl -M 2>/dev/null | grep cgi
httpd -M 2>/dev/null | grep cgi

# CGIディレクトリにBashスクリプトがないか確認
grep -rl "#!/bin/bash" /var/www/cgi-bin/ 2>/dev/null
grep -rl "#!/usr/bin/env bash" /var/www/cgi-bin/ 2>/dev/null

# 不要なCGIモジュールを無効化（Debian/Ubuntu系）
sudo a2dismod cgi
sudo systemctl restart apache2

5. 組み込み機器・NASのファームウェア更新

組み込みLinux機器では、ディストリビューションのパッケージ管理が使えません。メーカーのサポートページにアクセスし、Shellshock対応のファームウェアアップデートが公開されているか確認します。サポート終了製品は交換を検討してください。

中小企業でも今日からできること

現代のクラウドサーバーやVPSでは多くの場合パッチが適用済みですが、以下の環境では今なお確認が必要です。

・古いNASのファームウェア確認: 長期間ファームウェアを更新していないNAS製品はBashが脆弱なままのことがある。メーカーのサポートページで更新履歴を確認する
・産業用ルーター・IPカメラ等の組み込み機器: 組み込みLinuxでBashが使われている場合、メーカーのセキュリティ情報を定期確認する
・レガシーサーバーの棚卸し: 社内の「誰も触っていないサーバー」を洗い出してBashバージョンを確認する。Nmapを使ったネットワークスキャンと組み合わせると漏れなく調査できる
・CGIスクリプトの現代化: Bashで書かれた古いCGIスクリプトが残っている場合、Python・PHP・Node.jsへの移行を検討する
・脆弱性スキャンの定期実施: NmapのNSEスクリプト（http-shellshock）を使って社内WebサーバーのShellshock残存リスクを定期確認する

よくある誤解と注意点

・「2014年の古い脆弱性だから自社は関係ない」→ パッチ適用済みの主要ディストリビューションでは問題ありませんが、組み込み機器・古いNAS・レガシーサーバーでは今なお未パッチのものが存在します。「古いから大丈夫」という思い込みが盲点になります
・「bashを直接呼び出していなければ安全」→ CGIスクリプトや設定スクリプトが間接的にBashを呼び出している場合があります。シバン行（#!/bin/bash や #!/usr/bin/env bash）が入っているスクリプトを洗い出して確認することが重要です
・「Webサーバーを使っていないから大丈夫」→ CGI以外にもDHCPクライアントやSSH ForceCommandなど複数の攻撃経路があります。CGIを利用していないからといって完全に安全とは言えません
・「CVSSが10.0でも実際には悪用が難しいのでは」→ CGI環境さえあればネットワーク越しに比較的容易に悪用でき、自動化されたスキャンと組み合わせた攻撃も記録されています。過信は禁物です

本記事のまとめ

Shellshockは「古い脆弱性」ですが、見落とされがちな組み込み機器やレガシーサーバーでは現役の脅威です。脆弱性管理の4ステップと組み合わせて、定期的な棚卸しと確認を習慣づけることが確実な防御につながります。