RegreSSHion: glibcベースのLinuxシステムにおけるOpenSSHサーバーのリモートコード実行（RCE）

 (qualys.com)
1 ポイント 投稿者 GN⁺ 2024-07-02 | 1件のコメント | WhatsAppで共有

要約

  • OpenSSHのセキュリティ脆弱性を発見: OpenSSHサーバー（sshd）で、シグナルハンドラの競合状態に起因するリモートコード実行（RCE）脆弱性が発見された。この脆弱性はデフォルト設定の sshd に影響する。
  • 脆弱性の起源: この脆弱性は、2006年に報告された CVE-2006-5051 のリグレッションであり、2020年10月に OpenSSH 8.5p1 に導入されたコード変更によって発生した。
  • 脆弱性の影響: glibcベースのLinuxシステムでリモートから悪用可能であり、sshd の特権コードに影響して、root権限でのリモートコード実行が可能になる。
  • 脆弱性の悪用方法: この脆弱性を悪用するには、特定のコードパスを見つけ、それを適切なタイミングで中断させる必要がある。そのため、古い OpenSSH バージョンから始めて最新バージョンへと拡張した。
  • パッチと緩和策: 脆弱性を解決するためのパッチと緩和策が提供されている。

SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3（Debian 3.0r6、2005年）

理論

  • SIGALRM ハンドラ: このバージョンの SIGALRM ハンドラは packet_close() を呼び出し、これは buffer_free() を呼び出し、さらに xfree() と free() を呼び出す。free() は非同期シグナル安全ではない。
  • malloc コード分析: malloc コードにおいて、free() 呼び出しが SIGALRM によって中断され、SIGALRM ハンドラ内で再度呼び出されたときに、脆弱性を悪用できる経路が見つかった。

実践

  • 攻撃方法: DSA 公開鍵をパースするコード内で free() 呼び出しを中断させ、SIGALRM ハンドラ内でこれを悪用してリモートコード実行を達成する。
  • 競合状態での勝率: この競合状態に勝つには約 10,000 回の試行が必要で、平均すると約1週間かかる。

タイミング

  • タイミング戦略: ネットワーク遅延を最小化するため、最後のバイトを最後の瞬間に送信し、往復時間を追跡してタイミングを調整する。これにより、競合状態に勝つ確率を高める。

SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3（Ubuntu 6.06.1、2006年）

第1理論

  • SIGALRM ハンドラ: このバージョンの SIGALRM ハンドラは packet_close() を呼び出さず、malloc 関数が常にロックを取得するため、別の解決策が必要だった。
  • PAM の利用: PAM の pam_end() が非同期シグナル安全ではないことを発見し、これを悪用できる経路を探索した。

第2理論

  • pam_start() 分析: pam_start() が中断された場合、PAM 構造体が不整合な状態のまま残る可能性があり、これを SIGALRM ハンドラ内で悪用できる。
  • House of Mind 手法: 攻撃のために House of Mind 手法を用いてメモリ割り当てを操作し、root権限でのリモートコード実行を達成した。

実践

  • 攻撃方法: 長いユーザー名を使ってメモリ割り当てを操作し、複数回の pam_start() 呼び出しによって競合状態に勝つ確率を高める。

タイミング

  • タイミング戦略: 以前の Debian バージョンで使用したタイミング戦略を再利用して、競合状態に勝つ確率を高める。平均で1〜2日を要する。

SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2（Debian 12.5.0、2024年）

理論

  • SIGALRM ハンドラ: このバージョンの SIGALRM ハンドラは syslog() を呼び出し、これは非同期シグナル安全でない関数群を呼び出す。
  • glibc 分析: glibc の syslog() は malloc を呼び出し、これは非同期シグナル安全ではない。また、glibc の malloc 関数はシングルスレッド時にはロックを取得しない。

パッチと緩和策

  • パッチ: OpenSSH 開発者にこの脆弱性を報告し、これを解決するためのパッチを提供した。

GN⁺の意見

  • セキュリティの重要性: OpenSSH は非常に重要なセキュリティソフトウェアであり、この脆弱性はきわめてまれな事例である。
  • 脆弱性悪用の難易度: この脆弱性を悪用するには、非常に精密なタイミングと多数の試行が必要となる。
  • 代替ソリューション: OpenSSH 以外にもさまざまなセキュリティソリューションが存在し、それらを併用するのが望ましい。
  • 技術的挑戦: この研究は非常に高い技術的挑戦を伴い、セキュリティ研究者に大きな刺激を与えうる。
  • 脆弱性の緩和: 最新のセキュリティパッチを適用し、セキュリティ設定を強化することが重要である。

関連記事

1件のコメント

 
GN⁺ 2024-07-02
Hacker Newsの意見

  • RCEの修正は、ほぼ1か月前に公に「ひっそりと」行われていた

    • PerSourcePenalties が有効だと、sshd(8) は子の事前認証セッションプロセスの終了状態を監視する
    • クライアントが認証を繰り返し試行した場合や sshd がクラッシュした場合にペナルティを記録する
    • このパッチはバイナリアーキテクチャを変更し、特定の脆弱性を除去するとともに、エクスプロイトのクラス全体を緩和する

  • バグを導入した diff では、関数が次のようにリファクタリングされた

    • 元の関数: sigdie(const char *fmt,...)
    • リファクタリング後の関数: sshsigdie(const char *file, const char *func, int line, const char *fmt, ...)
    • #ifdef が欠落していた
    • もっと多くの人がプルリクエストをレビューしていれば防げたはず

  • OpenSSH リリースノートの興味深いコメント

    • 32ビット Linux/glibc システムで、ASLR と併用した成功するエクスプロイトが実証された
    • 64ビットシステムでも可能と思われる

  • OpenBSD は、SIGALRM ハンドラが syslog_r() を呼び出すため、この脆弱性の影響を受けない

    • 非同期シグナルセーフ版の syslog() を使っている
    • シグナルハンドラ内のコード量を最小化するリファクタリングが必要だった

  • musl の syslog(3) を調査したところ、glibc とは異なり容易にはエクスプロイトされない

    • すべてがスタック上、または再入保護された静的変数にある

  • FreeBSD 向けパッチが出ており、glibc を使っていないため影響を受けない可能性が高い

  • sshd_config ファイルで LoginGraceTime 0 を設定すると、この問題を緩和できる

    • その代わりサービス拒否攻撃に対して脆弱になるが、リモートコード実行は防げる

  • Debian 12 向けパッチが出ており、Debian 11 は影響を受けない

  • OpenSSH リリースノートと最小パッチへのリンクあり

  • 独立した立場では、単一の脆弱性を見つけるだけで十分であるべきだと思う

    • 人々が深刻に受け止めたり報奨金を支払ったりするには、チェーン全体を見つけることが求められがち