regreSSHionとは何か
regreSSHion (CVE-2024-6387)とは、2024年6月20日にQualys社によって報告された、1400万台以上のマシンにおいて、OpenSSHを経由した任意コード実行が可能になる脆弱性の名称です。脆弱性が存在するバージョンは8.5p1以上、9.7p1以下となります。ただし、対策パッチが適用されていないものに限ります。
そもそもOpenSSHとは?
OpenSSHはOpenBSDというOSのために開発されたSSHプロトコルを経由してマシンの遠隔操作を可能にするソフトウェアです。しかし実際にはポータブル版というものがあり、Linux等でも実行可能になっています。そのため、CentOS、AlmaLinuxやUbuntuをはじめとする多数のOSにおいて、標準で採用されています。
regreSSHionの攻撃難易度・危険度は?
さて、この脆弱性ですが、成功するまでの難易度は高いです。それは、OSのbit数によれど、成功まで平均数時間～1週間程度は時間がかかり、その間断続的に攻撃を受けることになるため、この間にOpenSSHがクラッシュしたり、または負荷などから異常を検知される可能性が高いためです(ただし、常時モニタリングをしていない場合、気付かず攻撃が通ってしまう可能性はありますので、Zabbixなどを利用してモニタリングすることをおすすめします)。さらに最近ではNX bit(実行不可属性)やASLR(アドレス空間配置のランダム化)といった防護技術が実装されているため、難易度が上がっているためです。
とはいえ、万が一攻撃が成功してしまうとサンドボックスもないので、遠隔で認証もなしにroot権限で任意のコードを実行できてしまう致命的なものとなっています。つまり、root権限で任意のコードが実行できるということは、実質そのマシンでなんでも実行できてしまい、乗っ取られたも同然ということです。そのため、CVEスコアは10点中8.1点と、高い数値で評価されています。
regreSSHionのKUSANAGIにおいての対応
KUSANAGI 9のAlmaLinux 8版では8.0p1を利用しているため、影響を受けません。よって、特段の対処は不要です。
しかし、AlmaLinux 9やCentOS Stream 9版では8.7p1の未修正バージョンを利用していたことがあるため、影響を受けます。
つまり、AlmaLinux 9やCentOS Stream 9ベースのKUSANAGIを利用している場合は、以下に提示する対応をとる必要があります:
OpenSSHのアップデートLoginGraceTimeを0にするfirewall-cmdなどを利用し、SSHデーモンへのアクセスできる端末を制限する
OpenSSHのアップデート
まず、1のOpenSSHのアップデートですが、これはAlmaLinux 9においては2024年7月2日現在すでに利用可能となっており、以下のコマンドですぐに対処可能です。
sudo dnf upgrade opensshこれにより、openssh-8.7p1-38からregreSSHion関連対策のパッチが適用されたopenssh-8.7p1-38.alma.2へアップデートされ、対処が完了します。
なお、CentOS Stream 9においては、2024年7月2日現在、まだ対策が提供されていません。
ついては、提供までの間、選択肢2もしくは3の利用を検討する必要があります。
LoginGraceTimeを0にする
2のLoginGraceTimeを0にする選択をした場合、/etc/ssh/sshd_configにてLoginGraceTimeを含む設定がされているかを検索の上、なされていればその値を0に変更、なされていなければ以下の項目を追記し、sshdを再起動します:
LoginGraceTime 0ただし、この対応には弱点があります。それは、DoS攻撃に弱くなってしまうということです。
SSHデーモンでは、受け付けられる接続数に上限があります。上限にあたると、他の接続が切れるまでは新規接続ができなくなってしまいます。
そして、LoginGraceTimeを0にするということは、ログイン前の段階で接続を張りっぱなしで放置していてもサーバ側では自動的に切断をしないということです。それにより、本当にログインしたいクライアントができなくなる恐れがあります。
ですのでregreSSHionに対策できるまで暫定的に利用するのが良いでしょう。
アクセスできる端末を制限する
最後に、3のfirewall-cmdなどを利用し、SSHデーモンへのアクセスできる端末を制限する方法です。
これは、信頼された端末からのみSSHデーモンへの接続を許可することを意味します。それによって、この脆弱性が悪用されたり、不正ログインされるリスクを低減できます。
ただし、この方法にも弱点があります。外部からアクセスがしにくくなるということです。たとえば固定IPやVPNなどを使い、アクセスできるようにすれば確かに制限はしやすいです。しかし、それらを使わずにアクセスしようとすると、この方法は使いにくくなります。
そのような問題を解決できるのであれば、以下のコマンドで対応が可能です。
IPアドレスは192.0.2.1、CIDRは32としていますが、こちらはそれぞれお持ちのグローバルIPや所有範囲に読み替えてください。
なお、SSH経由で不用意に実行するとアクセス不能になるリスクがあります。ご注意ください:
sudo dnf install firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --new-zone=ssh-allow
sudo firewall-cmd --permanent --zone=ssh-allow --add-source=192.0.2.1/32
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reloadregreSSHionはなぜ起きたのか。なぜ攻撃が成立するのか。
なぜこの脆弱性が発生したのかというと、大きく分けて2つあります。1つは、Linuxで利用するglibc (GNU C Library)というライブラリの仕様によるところ。もう一つは、うっかりミスということにあります。
glibcの仕様
SSHログインが一定の時間に完了しない場合、SIGALRMシグナルが発生します。これのハンドラとして、sigdie関数が実行されます。SIGALRMは、glibcの仕様上、非同期に実行されます。そして、sigdieの中ではsyslogというロギング関数を呼び出しています。ですが、このロガーは非同期に実行されうるもので使用することは安全ではありません。これをAS-Unsafe (Async-Signal Unsafe - 非同期シグナル安全ではない)といいます。AS-Unsafeの関数を利用しているのに「シグナルハンドラの競合状態」が起きた結果、ヒープが破壊され(バッファオーバーラン)、攻撃が成立するのです。
なお、CentOS StreamのGitLabでは、このsyslogに記録する部分をバイパスするパッチが提案されています。なお、このパッチはAlmaLinuxではすでに取り入れられています。また、OpenSSHでも今後はシグナルハンドラを利用するのではなくリスナーで処理することで、非同期処理を回避するよう改善されました。
うっかりミス
そして、実はまったく同じ脆弱性が2006年のOpenSSH 4.4p1においても発覚しており(CVE-2006-5051)、その時点で修正(#ifdef DO_LOG_SAFE_IN_SIGHANDが追加)されてリリースされています。
しかし、その後2020年に入り、OpenSSHをリファクタリングした際に当該の安全機構をうっかり取り除いてしまったがゆえに再度同じ脆弱性を生んだ(regreSSHionの名称の由来ともなっている)ということになります。
まとめ
この記事のまとめとしては、以下のようになります:
- regreSSHionは、2006年に修正した脆弱性が2020年に回帰し、4年後に発覚したもの
- root権限で任意のコードが遠隔実行される可能性がある
- CVEスコアは8.1と高め
- だが、発生確率は低い(難易度が高く、時間を要する)
AlmaLinux 9やCentOS Stream 9ベースのKUSANAGIでは影響を受ける- 2024年7月2日現在、AlmaLinux 9では修正アップデートがすでに提供されている
- CentOS Stream 9では提供待ち
- regreSSHionへの対応策は大きく分けて3つある
- 修正アップデートの速やかな適用
- 設定の変更
- アクセス制限の実施
- 任意実行の仕組みはシグナルハンドラ競合由来のバッファオーバーランによるヒープ破壊
- リファクタリング時のうっかりミスで再度エンバグ
これを踏まえて言えることが4つあります。一つ、ヒューマンエラーはどんなに有名なプロジェクトでも起きうること。二つ、長年発覚していない脆弱性やバグもあること。三つ、熟練した開発者でも脆弱性を埋め込んでしまうことがあること。四つ、速やかなアップデートの適用が安全性を向上する最善策であることです。なお、速やかなアップデートの適用については、OpenSSHのみならず、WordPressを含めた多くのソフトウェアで推奨されています。
当記事がこの脆弱性の理解や、安全な運用の一助になれば幸いです。
