Fiderにテナント越えの認証回避の脆弱性、0.36.0で修正
Fiderを複数組織向けのマルチテナント構成で運用していると、別の組織のボードに不正にログインされるおそれがあります。0.36.0で修正済みのため、HOST_MODEの設定を確認し、該当すれば更新してください。
急ぎ度: 早めに
CVSS v3は9.6で、ネットワーク越しに低い権限から悪用できますが、影響を受けるのは複数組織を1つのFiderに載せる構成に限られ、修正版の0.36.0が公開されています。
関係があるか
1つのFiderで複数の組織や製品のボードを運用している環境（HOST_MODE=multi）が対象です。既定のHOST_MODE=singleで動かしている環境は影響を受けません。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Fider（getfider/fider）、HOST_MODE=multi | 0.36.0より前のすべての版 | 0.36.0 |
| Fider（getfider/fider）、HOST_MODE=single（既定） | 影響なし | 対応は不要です。ただし0.36.0には別のセキュリティ修正も含まれます |
確かめ方
- 1Fiderの環境変数HOST_MODEの値を確認します。multiなら対象で、singleまたは未設定（既定はsingle）なら、この脆弱性の対象外です。
- 2コンテナで動かしている場合は、使用中のイメージの版を確認し、0.36.0より前でないかを見ます。
- 3自社で運用せず、外部が提供するFiderのサービスを使っている場合は、提供元の告知で0.36.0相当への更新状況を確認します。
何が起きたか
Fiderをマルチテナント構成で動かしていると、ある組織のボードで発行されたメール認証用の鍵が、別の組織のボードでも有効なものとして受け付けられます。これを使うと、鍵の発行元と同じメールアドレスで別のテナントにログインでき、テナントごとにデータを分ける仕組みが破られます。
原因は、認証用の鍵を探すデータベースの問い合わせに、テナントを絞り込む条件が抜けていたことです。鍵のテーブルは本来テナントと鍵の組で一意になる設計ですが、鍵だけで検索していたため、別のテナントで発行された記録がそのまま使われました。同じファイルの似た問い合わせにはテナントの条件が入っており、一部の処理だけが漏れていた形です。
この問題はCWE-639（利用者が操作できるキーによる認可の回避）に分類されています。0.36.0で修正されました。
攻撃の流れ
-
1
足がかりの取得
同じFiderのいずれかのテナントで、通常のアカウントを用意します。
-
2
認証用の鍵を入手
そのテナントでログイン用のメールを請求し、自分宛ての認証用の鍵を受け取ります。
-
3
別テナントへ提示
狙うテナントのログイン確認に、受け取った鍵を使います。
-
4
テナントを確認せず認証
Fiderが鍵の発行元テナントを見ずに処理し、狙ったテナントでログインが成立します。
どう悪用されるか
攻撃者は、同じFiderの任意のテナントでアカウントを持っていれば足ります。ネットワーク越しに操作でき、攻撃の難しさは低く、被害を受ける側の利用者の操作も要りません。管理者権限などの特別な権限も不要です。
攻撃者のメールアドレスが、別のテナントですでに管理者として登録されていれば、その管理者権限でログインされます。そのテナントに未登録のアドレスなら、攻撃者のメールアドレスで新しいアカウントが、気づかれないまま作られます。
どちらの場合も、他組織のボードの内容が読まれ、投稿や設定が書き換えられるおそれがあります。可用性への影響は想定されておらず、被害は機密性と完全性に集中します。
今すぐやること
-
1
HOST_MODEの値を確認する
Fiderの設定でHOST_MODEがmultiかどうかを確かめます。singleか未設定なら、この脆弱性の対象外です。
docker exec <コンテナ名> printenv HOST_MODE -
2
0.36.0へ更新する
マルチテナント構成なら修正版の0.36.0に更新します。リリースの案内では、通常のデプロイ手順（データベースのマイグレーションを実行し、再起動する）で足りるとされています。0.36.0には新しいマイグレーションが2件あるため、更新前にデータベースのバックアップを取っておくと安全です。
-
3
稼働中の版を確かめる
更新後、実際に動いているイメージやビルドが0.36.0以降になっているかを確認します。
docker image ls getfider/fider -
4
不審なログインやアカウントを調べる
各テナントのユーザー一覧と管理者一覧で、心当たりのないアカウントや、身に覚えのない管理者権限の操作がないかを見ます。修正版が出ているのに更新が遅れていた期間があれば、その期間を重点的に確認します。
背景
Fiderは、顧客や利用者から機能の要望や意見を集め、投票で優先度を測るためのオープンソースのフィードバックポータルです。HOST_MODE=multiでは、1つのFiderとデータベースに複数のボードが同居し、サブドメインごとにテナントを分けます。ボードの管理者は、顧客の発言や社内の要望といった、外に出したくない情報を扱うことが多いはずです。
この構成では、すべての問い合わせにテナントの条件を付けることで、組織間の壁を保っています。今回は認証用の鍵を探す1つの問い合わせだけが条件を欠いており、同じファイルの別の問い合わせは正しく絞り込んでいました。設計の考え方は合っていたのに、1か所が漏れた点が特徴です。
よくある質問
Q.0.36.0には、この脆弱性以外の修正も入っていますか。
まだ分かっていないこと
- GitHubの勧告には、実際の攻撃で悪用された事例の記載がありません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Fider is a feedback portal for feature requests and suggestions. Prior to version 0.36.0, in multi-tenant mode (HOST_MODE=multi), an attacker can use an email verification key issued by Tenant A to authenticate as the same email address on Tenant B. This completely bypasses tenant isolation and allows unauthorized account takeover across tenants. Single-host deployments (HOST_MODE=single, the default) are NOT affected. This issue has been patched in version 0.36.0.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory github.com
- advisory nvd.nist.gov
- web github.com