CVE-2018-10933-SSH認証のバイパス-libsshの脆弱性
CVE-2018-10933が本日リリースされたようで、libsshから概要を確認できます here
概要：
libsshバージョン0.6以降には、サーバーコードに認証バイパスの脆弱性があります。サーバーが認証の開始を期待するSSH2_MSG_USERAUTH_REQUESTメッセージの代わりにSSH2_MSG_USERAUTH_SUCCESSメッセージをサーバーに提示することにより、攻撃者は資格情報なしで認証に成功する可能性があります。
私はこれとその影響範囲をもっと理解しようとしています。 Debian、Ubuntuなどのオペレーティングシステムは、SSHをlibsshに依存していますか？そうであれば、SSHを公開するすべてのサーバーがこの攻撃に対して脆弱です？また、OpenSSHはlibsshに依存していますか、それとも2つの別々の実装ですか？ OpenSSHとlibsshを探してみましたが、探していたものが見つかりませんでした。この脆弱性はSSHの最悪のシナリオのように聞こえるので、私はそれが見出しを作ったり爆発したりしていないことに驚いています。この脆弱性の概要はあいまいなので、影響の範囲と、どのシナリオで心配すべきかについての洞察を探しています。
... OpenSSHはlibsshに依存していますか
OpenSSH（ほとんどのシステムで標準のSSHデーモンです）はlibsshに依存しません。
Openssh v.sを探してみました。 libssh ...
実際、 openssh libssh を検索すると、最初のヒットとして次のように表示されます： OpenSSH/Development libsshを含む 次のステートメント ： "... libsshは独立したプロジェクトです..."
また、OpenSSHが影響を受ける場合は、OpenSSHの公式サイトでそのような情報を見つけることができます。このサイトには、明示的に OpenSSH Security に関するページがあります。
Debianなどのオペレーティングシステムは、UbunutuはSSHのlibsshに依存していますか...
libsshの公式ドキュメント （少なくとも）誰が使用しているかを参照してください：KDE、GitHub ...
また、ご使用のOSで使用可能なパッケージまたはインストールされているパッケージがlibsshに依存していることを確認することもできます。例えばDebianおよび同様のもの（Ubuntuなど）の場合、これはapt rdepends libssh-4またはapt rdepends --installed libssh-4。
Libsshを使用しても、製品が自動的に脆弱になるとは限らないことに注意してください。まず、この問題はクライアントではなくSSHサーバーにlibsshを使用する場合にのみ関連するようです。そして、たとえサーバーの役割でlibsshを使用していても、サーバーの役割でも影響を受けるわけではありません。たとえば、 Githubは影響を受けないようです です。
Debian、Ubuntuのようなオペレーティングシステムは、SSHをlibsshに依存していますか？それは、SSHを公開するすべてのサーバーがこの攻撃に対して脆弱であることを意味しますか？
Libsshを使用するアプリケーションで問題が発生する可能性があります。 libssh website に記載されているように、「libsshは、SSHプロトコルを使用するプログラムを作成できるCライブラリです。」したがって、オペレーティングシステム自体ではなく、脆弱である可能性があるlibsshライブラリを利用するのはユーザーアプリケーションです。 libsshを使用するいくつかのアプリケーションを次に示します（libssh website から）：
- KDEはsftpファイル転送にlibsshを使用します
- GitHubはlibsshを使用してgit sshサーバーを実装しました
- X2GoはLinux用のリモートデスクトップソリューションです
また、OpenSSHはlibsshに依存していますか、それとも2つの別々の実装ですか？
いいえ、ありません。それらは別々です。
2018-10-18の更新：脆弱性発見者によって記述され、詳細な説明と概念実証コード（Paramiko経由）を含むブログ投稿は 現在利用可能 です。
リンク先のブログ投稿では、この脆弱性は、パケット処理ディスパッチテーブル（libssh\src\packet.c内）のコードがサーバーに対してもSSH2_MSG_USERAUTH_SUCCESSのハンドラーを実行する（そのようなメッセージは、クライアントによって処理されます）。コードをさらに調査すると、libssh\src\auth.cにあるメッセージのこのような誤った処理により、サーバーがセッション状態を認証済みに変更することがわかります。
詳細な概念実証コードも利用可能で、python Paramikoを更新してSSH2_MSG_USERAUTH_SUCCESSメッセージをSSH2_MSG_USERAUTH_REQUESTメッセージの代わりに送信し、脆弱性を悪用できることを示しています。
ただし、ブログの投稿には次のようにも記載されています。
「すべてのlibSSHサーバーが認証バイパスに対して必ずしも脆弱であるとは限りません。認証バイパスは、登録された認証コールバックに実行の機会を与えることなく内部libSSH状態マシンを認証済みに設定するため、追加のカスタムセッション状態を維持するlibSSHを使用して開発されたサーバーは失敗する可能性がありますこの状態が作成されずにユーザーが認証された場合に正しく機能するようにします。」
コマンドラインを介してアプリケーションの依存関係を表示するには、次のコマンドを実行できます。
ldd/usr/sbin/ssh
これにより、そのアプリケーションの依存関係が表示されます。このコマンドを実行しても、libsshは表示されません。つまり、libsshはOpenSSHの一部ではありません。