ディープダイブ

Dropbear：SSH制限の回避がrootソケットに到達

1つのTCP宛先に制限されたDropbearの鍵でも、宛先ごとの検査がストリーム転送を飛ばすため、docker.sockを含むUnixソケットを開けます。

Ostorlab Team 2026年11月14日

要点

DropbearはpermitopenとpermitlistenをTCP転送には適用しますが、Unixソケット転送には適用しません。1つのTCP宛先に制限された鍵でも、アカウントが到達できる任意のソケットを開けます。
2026.94までのすべてのDropbearリリースとGit HEAD 99baf182が影響を受けます。ローカルとリモートのストリーム転送オプションは既定で有効です。
研究者knellは、アカウントがDockerデーモンやデータベースソケットに到達できる場合を9.9と評価しています。CVEは割り当てられておらず、悪用も報告されておらず、2026年11月14日時点でCISAのKEVカタログにもありません。
修正版はありません。制限された鍵にno-port-forwardingを追加するか、ストリーム転送オプションを無効にしてDropbearを再ビルドしてください。各対策のコストは「修正方法」を参照してください。

影響を受けますか？

次の条件がすべて当てはまる場合に影響を受けます。

サーバーがDropbearを実行している。すべてのリリースとGit HEAD 99baf182（2026-11-11）までが対象です。
ビルドでUnixソケット転送が有効になっている。DROPBEAR_SVR_LOCALSTREAMFWDとDROPBEAR_SVR_REMOTESTREAMFWDは既定で1です。
少なくとも1つのauthorized_keysエントリにpermitopen=またはpermitlisten=が付いている。この制限は、鍵の保有者に一般的な到達性を任せないためのものです。
その鍵のアカウントが/var/run/docker.sockやデータベースソケットなどの重要なUnixソケットに到達できる。研究者の9.9のケースはDockerソケットです。
攻撃者がその制限付き鍵を保有しているか、それを保有するアカウントを使える。

permitopenもpermitlistenもない鍵はこの問題の対象ではありません。その保有者はすでに一般的な転送の到達性を持っています。この回避は、管理者が意図的に狭めた鍵で問題になります。

ブランチ	影響を受けるバージョン	修正バージョン
リリース	2026.94（2026-07-23）まで	なし
Git	`99baf182`（2026-11-11）まで	なし

サーバーのバージョンと制限付き鍵を確認します。

# Server and client version
dropbear -V

# Keys that carry a per-destination restriction
grep -R -E 'permitopen=|permitlisten=' /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

# Accounts that can reach the Docker socket
getent group docker

重要なのは鍵の一覧です。permitopen付きの鍵のアカウントがdockerグループにも入っている場合が、研究者の言う9.9のケースです。

修正方法

2026年11月14日時点で修正済みのDropbearリリースはありません。次の3つの緩和策を優先順に適用し、プロジェクトがパスベースの修正を公開したら外してください。

permitopenまたはpermitlistenを持つすべての鍵にno-port-forwardingを追加します。ストリーム転送ハンドラーはsvr_pubkey_allows_tcpfwd()を通じてこのフラグを確認するため、鍵はUnixソケットを開けなくなります。コストは、管理者が許可した宛先を含め、その鍵のTCP転送もすべて失うことです。
localoptions.hでDROPBEAR_SVR_LOCALSTREAMFWD 0とDROPBEAR_SVR_REMOTESTREAMFWD 0を設定してDropbearを再ビルドします。コストは、そのサーバーのどのアカウントもUnixソケット転送を使えなくなることです。
サーバーを-j -kで起動します。これらのフラグはnolocaltcpとnoremotefwdを設定し、ストリーム転送ハンドラーがそれを確認します。コストは、制限付き鍵だけでなくすべてのアカウントがローカルとリモートの転送を失うことです。

アカウントをdockerグループから外し、ソケットの権限を厳しくすると影響は下がります。回避は閉じません。鍵は、データベースやサービスを含め、アカウントが開ける他のソケットに依然として到達できます。

研究者は、TCP経路と同じリスト走査をsvr-streamfwd.cで適用する、パスベースのpermitopen相当の検査を推奨しています。Dropbearのリリースページでこの変更を監視してください。プロジェクトは修正版を公開していません。

根本原因は何ですか？

Unixソケット転送ハンドラーは、大まかなno-port-forwardingフラグだけを確認します。鍵の宛先リストを走査する関数を呼びません。

Dropbearは制限をauthorized_keysに保持します。src/svr-authpubkeyoptions.cの65行目にあるsvr_pubkey_allows_tcpfwd()は、鍵にno-port-forwardingがある場合にだけ0を返します。

int svr_pubkey_allows_tcpfwd() {
    if (ses.authstate.pubkey_options 
        && ses.authstate.pubkey_options->no_port_forwarding_flag) {
        return 0;
    }
    return 1;
}

宛先ごとの検査は同じファイルのsvr_pubkey_allows_local_tcpfwd()とsvr_pubkey_allows_remote_tcpfwd()にあります。src/svr-tcpfwd.cは202行目と99行目でそれらを呼びます。2つのストリーム転送ハンドラーは呼びません。

src/svr-streamfwd.cでは、ローカルハンドラーnewstreamlocal()が294行目でsvr_opts.nolocaltcpとsvr_pubkey_allows_tcpfwd()を確認します。リモートハンドラーsvr_remotestreamlocalreq()は219行目でsvr_opts.noremotefwdと同じ関数を確認します。ツリーを検索すると、宛先ごとの2つの関数はsrc/svr-tcpfwd.cからのみ参照されています。

既定のビルドはsrc/default_options.hの76行目と77行目で両方のストリーム転送オプションを有効にします。チャネルはsrc/svr-session.cで登録されます。

不完全な修正は履歴に残っています。コミット796a89ef（2024-04-03）「Apply tcp forwarding restrictions to unix sockets too」は、newstreamlocal()に大まかな検査を追加し、マニュアルを更新しました。タイトルが告げる宛先ごとの検査は追加していません。作者はsrc/svr-streamfwd.cの213行目と214行目で、streamlocalにpermitlisten相当のものがあれば検査を緩められると注記しています。それは存在しません。

どのように悪用されますか？

攻撃者は、管理者がpermitopen="host:port"で1つのTCP宛先に制限した鍵で認証します。
攻撃者はTCP宛先ではなく、Unixソケットのパスへdirect-streamlocal@openssh.comチャネルを開きます。
Dropbearのストリーム転送ハンドラーはno-port-forwardingフラグとサーバー全体の転送スイッチを確認します。鍵にno-port-forwardingがないため、両方を通ります。
ハンドラーはpermitopenリストを参照しないため、要求されたソケットへ接続します。
攻撃者はそのソケットのプロトコルを話します。/var/run/docker.sockでは、Docker APIがホストのファイルシステムをマウントしたコンテナを起動でき、ホストのrootに相当します。

研究者は固定したソースから構築したローカルの環境で回避を実証しました。permitopen="127.0.0.1:1"を持つ鍵は127.0.0.1:22を要求すると拒否されましたが、同じ鍵は/tmp/target.sockに到達しました。その後、同じ鍵で/var/run/docker.sockを開き、実際のデーモンからHTTP/1.1 200 OK, Api-Version 1.56を受け取りました。

リモート方向も同じです。permitlistenを持つ鍵は、書き込み可能な任意のUnixパスでサーバーを待ち受けさせ、サービスのソケットを隠すことができます。

攻撃の流れは？

制限付き鍵が大まかな転送検査を通り、TCP宛先ではなくUnixソケットを要求し、管理者が許可していないソケットに到達します。

flowchart LR A["攻撃者が1つのTCPホストへの
permitopen付き鍵を保有"] --> B["その鍵でDropbearへ
接続"] B --> C["docker.sockへの
direct-streamlocalチャネルを開く"] C --> D["ハンドラーは
no-port-forwardingだけを確認"] D --> E["permitopenリストは
参照されない"] E --> F["Dropbearがroot所有の
ソケットへ接続"] F --> G["Docker APIがホストの
ファイルシステム付きコンテナを実行"]

攻撃者に何ができますか？

鍵が1つのTCP宛先に制限されていても、攻撃者はアカウントが開けるUnixソケットに到達します。アカウントがDockerソケットに到達できる場合、それはホストのrootに相当します。

影響は、アカウントのOS識別子が触れられるソケットによります。

/var/run/docker.sockは、ホストのファイルシステムをrootでマウントしたコンテナを実行できます。研究者はこれをホストroot相当と呼んでいます。
/run/mysqld/mysqld.sockや/run/postgresql/.s.PGSQL.5432などのデータベースソケットは、データベースを鍵の保有者に露出します。
エージェントやサービスのソケットは、それらのサービスが受け付けるものを露出します。
permitlisten方向では、書き込み可能な任意のパスでサーバーを待ち受けさせ、サービスのソケットを隠せます。

条件は影響の一部です。攻撃者には有効な制限付き鍵が必要で、アカウントが対象ソケットを開ける必要があり、ビルドでストリーム転送が有効である必要があります。研究者はDockerのケースをCVSS v3.1 9.9、AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hと評価し、アカウント自身のソケットだけに到達できる場合は約7としています。

これは未認証の脆弱性ではありません。攻撃者は管理者が発行した鍵を保有しており、管理者はその鍵でできることを制限するために鍵を狭めていました。

修正が機能する理由

上流の修正はまだありません。回避を閉じる変更は、TCPハンドラーがすでに使う宛先ごとのリスト走査を、2つのストリーム転送ハンドラーにも適用します。

欠けている検査は両方のハンドラーで確認できます。src/svr-streamfwd.cの294行目のローカルハンドラーは現在こうなっています。

if (svr_opts.nolocaltcp || !svr_pubkey_allows_tcpfwd()) {

完全な検査では、要求されたソケットパスに対してsvr_pubkey_allows_local_tcpfwd()のパスベース相当も呼びます。鍵がそのパスを含まない宛先リストを持つ場合、チャネルを拒否します。219行目のリモートハンドラーにもpermitlistenの同じ変更が必要です。

研究者の推奨は、パスベースのオプションができるまで、宛先ごとの制限を持つ鍵のstreamlocalチャネルを一律に拒否することです。保守的な修正で、考え方も単純です。宛先を名指す鍵にはUnixソケットを与えない。

no-port-forwardingの緩和策は、既存の大まかな検査が読むフラグを設定するため機能します。ビルドと-j -kの緩和策は、ハンドラーが読むサーバー全体のスイッチを設定するため機能します。どれも、欠けているリスト走査のコード修正ではありません。

侵害されたかどうかを確認するには？

悪用は報告されておらず、侵害の指標も公開されていません。確認は既知のペイロードではなく、条件とソケットの使用を対象にします。

permitopenまたはpermitlistenを持つすべての鍵と、それを所有するアカウントを一覧にします。
それらのアカウントがdockerグループに入っているか、データベースソケットを開けるかを確認します。
Dockerデーモンの監査ログで、予期しないローカルプロセスやユーザーからのAPI呼び出し、特にホストのバインドマウントを伴うコンテナ作成を確認します。
データベースのログで、通常は接続しないOSユーザーからのローカルソケット接続を確認します。
チームの誰も作成していないコンテナ、イメージ、バインドマウントを探します。

Dropbearの既定のログは最小限で、分析はログ署名を公開していません。失敗した試行は痕跡を残さない場合があり、成功した試行はソケットが属するサービスに影響を残します。

年表

2024-04-03：コミット796a89efがTCP転送の大まかな制限をUnixソケットに適用するが、宛先ごとの検査は適用しない。
2025-12-09：コミット00cfa132が強制コマンド鍵のUnixストリーム転送をブロックする。同じ経路の別の制限。
2026-07-23：Dropbearが2026.94を公開する。
2026-11-11：研究者がGit HEAD 99baf182をテストし、回避が存在することを確認する。
2026-11-13：研究者が分析とライブ実証をoss-securityメーリングリストへ公開する。

不完全な修正から公開まで — 図1：大まかな制限は2024年4月に導入され、宛先ごとの半分は欠けたままでした。回避は2026年11月13日に公開されました。出典：DropbearのGit履歴とoss-securityの公開、2026年11月14日確認

よくある質問

この問題にCVEはありますか？

いいえ。研究者は2026年11月13日にoss-securityメーリングリストで分析を公開し、11月14日時点でCVEレコードはありません。Dropbearプロジェクトは勧告を公開していません。

permitopenはUnixソケットを保護しますか？

いいえ。permitopenとpermitlistenはTCP転送の経路にのみ適用されます。Unixソケットのハンドラーはno-port-forwardingフラグとサーバー全体の転送スイッチを確認し、宛先リストは確認しません。

これはリモートの未認証脆弱性ですか？

いいえ。攻撃者には、管理者がpermitopenまたはpermitlistenで制限した有効な鍵が必要です。重大度は、その鍵のアカウントが何に到達できるかによります。

どのバージョンが影響を受けますか？

2026.94までのすべてのDropbearリリースと、99baf182（2026-11-11）までのGit HEADです。2026年11月14日時点で修正版はありません。

no-port-forwardingは回避をブロックしますか？

はい。no-port-forwardingはsvr_pubkey_allows_tcpfwd()が読むフラグを設定するため、2つのストリーム転送ハンドラーがチャネルを拒否します。また、許可された宛先を含め、その鍵のTCP転送もすべてブロックします。

アカウントがdockerグループにない場合は？

攻撃者はデータベースやサービスのソケットなど、アカウントが開ける任意のソケットに依然として到達できます。影響はホストrootより小さいですが、鍵の制限が防ぐはずだった到達性は残ります。

参考資料

knell「Dropbear: the restriction names an address」、oss-security、2026年11月13日、分析とライブ実証：https://www.openwall.com/lists/oss-security/2026/11/13/4（2026年11月14日確認）
研究者の論文「Not an address」、完全な分析とテスト環境：https://archive.org/details/knell-not-an-address（2026年11月14日確認）
Dropbear 99baf182のソース、src/svr-streamfwd.c、2つのストリーム転送ハンドラー：https://github.com/mkj/dropbear/blob/99baf1828c13e88de048e641d03694bfe8923251/src/svr-streamfwd.c（2026年11月14日確認）
Dropbear 99baf182のソース、src/svr-authpubkeyoptions.c、大まかな検査と宛先ごとの検査：https://github.com/mkj/dropbear/blob/99baf1828c13e88de048e641d03694bfe8923251/src/svr-authpubkeyoptions.c（2026年11月14日確認）
Dropbear 99baf182のソース、src/default_options.h 76行目と77行目、ストリーム転送の既定値：https://github.com/mkj/dropbear/blob/99baf1828c13e88de048e641d03694bfe8923251/src/default_options.h（2026年11月14日確認）
コミット796a89ef「Apply tcp forwarding restrictions to unix sockets too」、2024年4月3日：https://github.com/mkj/dropbear/commit/796a89efd21f（2026年11月14日確認）
コミット00cfa132「Disallow unix stream forwarding for forced command」、2025年12月9日：https://github.com/mkj/dropbear/commit/00cfa132fcbf（2026年11月14日確認）
Dropbearプロジェクトページ、組み込みとルーターの用途、2026.94リリース：https://matt.ucc.asn.au/dropbear/dropbear.html（2026年11月14日確認）
CISA Known Exploited Vulnerabilitiesカタログ、2026年11月14日にDropbearの項目を確認（なし）：https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json（2026年11月14日確認）

ostorlab/KEV オープンソース

# 無料のオープンソース：このような既知の悪用された脆弱性がないか、自分のホストをスキャンしましょう。

$ pip install -U ostorlab
$ git clone https://github.com/Ostorlab/KEV && cd KEV
$ ostorlab scan run --install -g agent_group.yaml domain-name example.com

Ostorlab KEVは無料のオープンソース（Apache-2.0）です。1つのコマンドで、CISA KEVカタログ、Google Tsunami、バグバウンティプログラム由来の脆弱性を対象に、Nuclei、Tsunami、Nmap、Asteroid、Metasploitの検出器を実行します。

github.com/Ostorlab/KEV

タグ：

security, Dropbear, SSH, access control, privilege escalation, vulnerability

要点